lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Fri, 1 Mar 2019 12:19:07 +0000
From:   Ignat Korchagin <>
Cc:     Daniel Dao <>,
        Ivan Babrou <>,
        Frank Hofmann <>,
        Nicolae Vartolomei <>
Subject: noqueue qdisc and non-virtual interfaces

Good day,

According to this link: it should
not be possible to assign noqueue qdisc to physical devices or
classes. Yet, I can clearly do it even on the latest 5.0-rc series

$ sudo tc qdisc add dev eth0 root noqueue
$ sudo tc qdisc show dev eth0
qdisc noqueue 8005: root refcnt 385

If I understand the source correctly, noqueue qdisc was designed only
for network interfaces, which have IFF_NO_QUEUE in priv_flags in
net_device structure. However, I see no checks in the code, which
enforce it when attaching this qdisc to an interface.

I believe, it was not possible before, but commit
d66d6c3152e8d5a6db42a56bf7ae1c6cae87ba48 changed that.

Regardless, if it is intentional or not, the change is incomplete as
it introduces a potential NULL ptr dereference bug, which can be
triggered by doing something like:

sudo tc qdisc replace dev $dev root noqueue
sudo tc qdisc delete dev $dev root
sudo tc qdisc replace dev $dev root handle 1: htb default 1
sudo tc class add dev $dev parent 1: classid 1:1 htb rate 1000Gbps
sudo tc qdisc add dev $dev parent 1:1 handle 10: noqueue

I believe it should not be possible to have noqueue qdisc on physical
nics, but, please, let me know if I'm wrong.


Powered by blists - more mailing lists