CVE-2026-23074: net/sched: Enforce that teql can only be used as root qdisc

Published Feb 4, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

net/sched: Enforce that teql can only be used as root qdisc

Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.

Although not important, I will describe the scenario that unearthed this issue for the curious.

GangMin Kim <km.kim1503@gmail.com> managed to concot a scenario as follows:

ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql

GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfqchangeclass calls qfqdeactrmfromagg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.

Other sources

In the Linux kernel, the following vulnerability has been resolved:

net/sched: Enforce that teql can only be used as root qdisc

Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.

Although not important, I will describe the scenario that unearthed this issue for the curious.

GangMin Kim <km.kim1503> managed to concot a scenario as follows:

ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql

GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfqchangeclass calls qfqdeactrmfromagg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.

Red Hat

Affected Software

20 affected componentsFixes available
Linux Linux kernel
Linux Linux kernel>=2.6.12.1<5.10.249
Linux Linux kernel>=5.11<5.15.199
Linux Linux kernel>=5.16<6.1.162
Linux Linux kernel>=6.2<6.6.122
Linux Linux kernel>=6.7<6.12.68
Linux Linux kernel>=6.13<6.18.8
Linux Linux kernel=2.6.12
Linux Linux kernel=2.6.12-rc2
Linux Linux kernel=2.6.12-rc3
Linux Linux kernel=2.6.12-rc4
Linux Linux kernel=2.6.12-rc5
Linux Linux kernel=6.19-rc1
Linux Linux kernel=6.19-rc2
Linux Linux kernel=6.19-rc3
Linux Linux kernel=6.19-rc4
Linux Linux kernel=6.19-rc5
Linux Linux kernel=6.19-rc6
debian/linux<=5.10.223-1
5.10.251-56.1.170-36.1.172-16.12.86-16.12.88-17.0.7-1
debian/linux-6.1
6.1.172-1~deb11u1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade debian/linux to a version that resolves this vulnerability.

    Fixed in 5.10.251-5Fixed in 6.1.170-3Fixed in 6.1.172-1Fixed in 6.12.86-1Fixed in 6.12.88-1Fixed in 7.0.7-1
  2. Upgrade

    Upgrade debian/linux-6.1 to a version that resolves this vulnerability.

    Fixed in 6.1.172-1~deb11u1
  3. Upgrade

    Upgrade linux kernel net/sched to a version that resolves this vulnerability.

    Patch net/sched: Enforce that teql can only be used as root qdisc
  4. Compensating control

    Ensure teql is only configured/used as a root qdisc (design intent stated in the resolved vulnerability description: “teql is only supposed to be used as root qdisc”).

Event History

Feb 4, 2026
CVE Published
via MITRE·04:07 PM
Data Sourced
via MITRE·04:07 PM
DescriptionSeverity
Data Sourced
via Red Hat·05:03 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·05:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
May 14, 2026
Data Sourced
via Ubuntu·04:06 AM
RemedyDescriptionSeverityAffected Software
May 18, 2026
Data Sourced
via Debian·04:11 AM
DescriptionAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-23074?

CVE-2026-23074 is categorized as a high-severity vulnerability due to improper enforcement of root qdisc usage.

2

How do I fix CVE-2026-23074?

To fix CVE-2026-23074, ensure you update the Linux kernel to the latest version where this vulnerability has been patched.

3

What impact does CVE-2026-23074 have on system security?

CVE-2026-23074 can potentially allow non-root users to interact with the queuing discipline, leading to security implications.

4

Which versions of the Linux kernel are affected by CVE-2026-23074?

CVE-2026-23074 affects all versions of the Linux kernel prior to the patches that enforce the root qdisc constraint.

5

What component of the Linux kernel is affected by CVE-2026-23074?

CVE-2026-23074 affects the net/sched component of the Linux kernel, specifically the Traffic Equalizer (teql) queuing discipline.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203