Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

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&amp;#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-&gt;q.qlen)<br /> at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#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&amp;#39;s lmax value,<br /> the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#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&amp;#39;s delay), a dangling pointer is<br /> accessed causing GangMin&amp;#39;s causing a UAF.

Impacto