CVE-2026-90071: net/sched: sch_teql: restore skb->dev on the slave failure path
In the Linux kernel, the following vulnerability has been resolved:
net/sched: schteql: restore skb->dev on the slave failure path
teqlmasterxmit() sets skb->dev = slave before calling the slave's ndostartxmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one.
If a later slave has no resolved neighbour, teqlresolve() hands the skb to neigheventsend(), which queues it on that neighbour's arpqueue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the netdevice while the skb is still queued. Whatever runs next on that skb - arperrorreport() on timeout, or neighdirectoutput() -> devqueuexmit() once the neighbour resolves - causes a UAF like the one below:
BUG: KASAN: slab-use-after-free in icmpsend (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task floodpacket/527 CPU: 0 UID: 0 PID: 527 Comm: floodpacket Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) printreport (mm/kasan/report.c:378 mm/kasan/report.c:482) ? pfxrawspinlockirqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? icmpsend (net/ipv4/icmp.c:914 (discriminator 2)) kasanreport (mm/kasan/report.c:595) ? icmpsend (net/ipv4/icmp.c:914 (discriminator 2)) icmpsend (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4linkfailure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? pfxipv4linkfailure (./include/linux/skbuff.h:4327) ? rawwritelock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlockapismp.h:230 kernel/locking/spinlock.c:304) ? pfxrawwritelock (kernel/locking/spinlock.c:175) arperrorreport (./include/net/dst.h:438 net/ipv4/arp.c:296) neighinvalidate (net/core/neighbour.c:1077) neightimerhandler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasankmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) kvmallocnodenoprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) allocnetdevmqs (net/core/dev.c:12055 (discriminator 2)) rtnlcreatelink (net/core/rtnetlink.c:3721) rtnlnewlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlinkrcvmsg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasansavefreeinfo (mm/kasan/generic.c:584) kasanslabfree (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) devicerelease (drivers/base/core.c:2636) kobjectput (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdevruntodo (net/core/dev.c:11756) rtnldellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlinkrcvmsg (net/core/rtnetlink.c:7076) [...]
Fix this by restoring skb->dev to the master at the end of each slave's iteration.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Patch the kernel networking code so that on the teql slave failure path (sch_teql), the code restores skb->dev to the teql master before the skb continues; this prevents a use-after-free where arp_error_report() on timeout (or __icmp_send) observes a stale skb->dev that points to a previous (freed) net_device.
Linux kernel networking (net/ipv4/icmp.c / net/core neighbour/teql) skb->dev restore on teql slave failure path = Restore skb->dev back to the master at the end of each slave's failure path (e.g., sch_teql) when transmit/neigh resolution fails
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
Traffic must be transmitted through the sch_teql scheduler such that one slave transmit fails, a later slave lacks a resolved neighbour, and the earlier slave is then deleted while the packet remains queued on the later neighbour's ARP queue. The issue can subsequently trigger when the queued packet is processed after neighbour timeout or resolution.
Which systems are realistically exposed?
Systems using the Linux kernel's sch_teql traffic scheduler with multiple slave devices are exposed when the described failed-transmit, unresolved-neighbour, and slave-deletion sequence can occur. The provided information does not establish that systems not using sch_teql are affected.
What can be done if the fix cannot be deployed immediately?
Avoid deleting a TEQL slave device while packets may remain queued for unresolved neighbours after a transmit failure. Reducing or avoiding use of sch_teql configurations involving multiple slaves and unresolved neighbour traffic also avoids the described trigger path.
How can an affected system manifest the issue?
The vulnerability can produce a kernel use-after-free when a queued packet is later handled, including through arp_error_report() after neighbour timeout or through neigh_direct_output() and dev_queue_xmit() after neighbour resolution. The report includes a KASAN slab-use-after-free observed in __icmp_send.