CVE-2026-23074
Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
04/02/2026
Última modificación:
04/02/2026
Descripción
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
net/sched: Enforce that teql can only be used as root qdisc<br />
<br />
Design intent of teql is that it is only supposed to be used as root qdisc.<br />
We need to check for that constraint.<br />
<br />
Although not important, I will describe the scenario that unearthed this<br />
issue for the curious.<br />
<br />
GangMin Kim managed to concot a scenario as follows:<br />
<br />
ROOT qdisc 1:0 (QFQ)<br />
├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s<br />
└── class 1:2 (weight=1, lmax=1514) teql<br />
<br />
GangMin sends a packet which is enqueued to 1:1 (netem).<br />
Any invocation of dequeue by QFQ from this class will not return a packet<br />
until after 6.4s. In the meantime, a second packet is sent and it lands on<br />
1:2. teql&#39;s enqueue will return success and this will activate class 1:2.<br />
Main issue is that teql only updates the parent visible qlen (sch->q.qlen)<br />
at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&#39;s<br />
peek always returns NULL), dequeue will never be called and thus the qlen<br />
will remain as 0. With that in mind, when GangMin updates 1:2&#39;s lmax value,<br />
the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&#39;s<br />
qlen was not incremented, qfq fails to deactivate the class, but still<br />
frees its pointers from the aggregate. So when the first packet is<br />
rescheduled after 6.4 seconds (netem&#39;s delay), a dangling pointer is<br />
accessed causing GangMin&#39;s causing a UAF.



