FlawAtlas
Search the atlas
CVE-2026-23074 Not scored

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

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 <[email protected]> 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 qfq_change_class calls qfq_deact_rm_from_agg. 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.

Exploit probability 0.1%
Published February 4, 2026
Required by Not available
Last source change July 16, 2026

02 / AFFECTED SOFTWARE

Affected packages

Linux Kernel
Unknown Unknown

1698 explicit affected versions

03 / CONNECTIONS

Connected vulnerabilities

related ALSA-2026:3083
related ALSA-2026:3110
related OPENSUSE-SU-2026:20416-1
related SUSE-SU-2026:0617-1
related SUSE-SU-2026:0928-1
related SUSE-SU-2026:0961-1
related SUSE-SU-2026:0962-1
related SUSE-SU-2026:1003-1
related SUSE-SU-2026:1041-1
related SUSE-SU-2026:1077-1
related SUSE-SU-2026:1078-1
related SUSE-SU-2026:1081-1
related SUSE-SU-2026:1130-1
related SUSE-SU-2026:1131-1
related SUSE-SU-2026:1180-1
related SUSE-SU-2026:1185-1
related SUSE-SU-2026:1187-1
related SUSE-SU-2026:1188-1
related SUSE-SU-2026:1189-1
related SUSE-SU-2026:1212-1
related SUSE-SU-2026:1221-1
related SUSE-SU-2026:1222-1
related SUSE-SU-2026:1225-1
related SUSE-SU-2026:1236-1
related SUSE-SU-2026:1237-1
related SUSE-SU-2026:1239-1
related SUSE-SU-2026:1242-1
related SUSE-SU-2026:1244-1
related SUSE-SU-2026:1248-1
related SUSE-SU-2026:1254-1
related SUSE-SU-2026:1258-1
related SUSE-SU-2026:1259-1
related SUSE-SU-2026:1261-1
related SUSE-SU-2026:1262-1
related SUSE-SU-2026:1263-1
related SUSE-SU-2026:1265-1
related SUSE-SU-2026:1266-1
related SUSE-SU-2026:1268-1
related SUSE-SU-2026:1269-1
related SUSE-SU-2026:1270-1
related SUSE-SU-2026:1271-1
related SUSE-SU-2026:1272-1
related SUSE-SU-2026:1274-1
related SUSE-SU-2026:1278-1
related SUSE-SU-2026:1279-1
related SUSE-SU-2026:1280-1
related SUSE-SU-2026:1281-1
related SUSE-SU-2026:1283-1
related SUSE-SU-2026:1284-1
related SUSE-SU-2026:1285-1
related SUSE-SU-2026:1287-1
related SUSE-SU-2026:1288-1
related SUSE-SU-2026:1293-1
related SUSE-SU-2026:1294-1
related SUSE-SU-2026:1297-1
related SUSE-SU-2026:1298-1
related SUSE-SU-2026:1304-1
related SUSE-SU-2026:1305-1
related SUSE-SU-2026:20667-1
related SUSE-SU-2026:20720-1
related SUSE-SU-2026:20838-1
related SUSE-SU-2026:20845-1
related SUSE-SU-2026:20876-1
related SUSE-SU-2026:20931-1
related SUSE-SU-2026:21004-1
related SUSE-SU-2026:21005-1
related SUSE-SU-2026:21006-1
related SUSE-SU-2026:21007-1
related SUSE-SU-2026:21008-1
related SUSE-SU-2026:21009-1
related SUSE-SU-2026:21020-1
related SUSE-SU-2026:21040-1
related SUSE-SU-2026:21041-1
related SUSE-SU-2026:21042-1
related SUSE-SU-2026:21043-1
related SUSE-SU-2026:21044-1
related SUSE-SU-2026:21045-1
related SUSE-SU-2026:21046-1
related SUSE-SU-2026:21047-1
related SUSE-SU-2026:21048-1
related SUSE-SU-2026:21049-1
related SUSE-SU-2026:21050-1
related SUSE-SU-2026:21051-1
related SUSE-SU-2026:21052-1
related SUSE-SU-2026:21053-1
related SUSE-SU-2026:21054-1
related SUSE-SU-2026:21055-1
related SUSE-SU-2026:21056-1
related SUSE-SU-2026:21057-1
related SUSE-SU-2026:21058-1
related SUSE-SU-2026:21059-1
related SUSE-SU-2026:21060-1
related SUSE-SU-2026:21061-1
related SUSE-SU-2026:21070-1
related SUSE-SU-2026:21071-1
related SUSE-SU-2026:21072-1
related SUSE-SU-2026:21073-1
related SUSE-SU-2026:21074-1
related SUSE-SU-2026:21075-1
related SUSE-SU-2026:21076-1
related SUSE-SU-2026:21077-1
related SUSE-SU-2026:21078-1
related SUSE-SU-2026:21079-1
related SUSE-SU-2026:21080-1
related SUSE-SU-2026:21081-1
related SUSE-SU-2026:21082-1
related SUSE-SU-2026:21083-1
related SUSE-SU-2026:21084-1
related SUSE-SU-2026:21085-1
related SUSE-SU-2026:21086-1
related SUSE-SU-2026:21087-1
related SUSE-SU-2026:21088-1
related SUSE-SU-2026:21089-1
related SUSE-SU-2026:21090-1
related SUSE-SU-2026:21091-1
related SUSE-SU-2026:21096-1
related SUSE-SU-2026:21098-1
related SUSE-SU-2026:21099-1
related SUSE-SU-2026:21100-1
related SUSE-SU-2026:21102-1
related SUSE-SU-2026:21216-1
related SUSE-SU-2026:21217-1
related SUSE-SU-2026:21218-1
related SUSE-SU-2026:21219-1
related SUSE-SU-2026:21220-1
related SUSE-SU-2026:21221-1
related SUSE-SU-2026:21284-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2026-23074

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 <[email protected]> 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 qfq_change_class calls qfq_deact_rm_from_agg. 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.

View original source

05 / REFERENCES

Further evidence