Look up another CVE · open CVE-2026-90071 in the interactive tracker
CVE-2026-90071
net/sched: sch_teql: restore skb->dev on the slave failure path
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem net/sched. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90071 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), 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, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (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) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/sched/sch_teql.c
- What this is
- TC subsystemMAINTAINERS section matched on net/sched/ · netdev@vger.kernel.org · Maintained
- Kernel module
- sch_teql
Check it on the machine
grep -w CONFIG_NET_SCH_TEQL /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w sch_teqlPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_NET_SCH_TEQL
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 4.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/sched
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.10.253 | 5.10.270 | 1360bc93f5be |
| 5.15.203 | 5.15.221 | d453bf439ef2 |
| 6.1.167 | 6.1.188 | 012559cf3c67 |
| 6.6.130 | 6.6.157 | aa39a790d56b |
| 6.12.78 | 6.12.110 | 00d8a387b23b |
| 6.18.19 | 6.18.52 | 96bc345a3f17 |
| 7.0 | 7.2.6 | 0cd750379485 |
| 7.0 | 7.3 | dc4b95b8fee9 |
| 6.19.9 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- teql_master_xmit() itself writes skb->dev to the slave, and the UAF is completed by a local RTM_DELLINK (rtnl_dellink → netdev_run_todo) of that slave while the skb sits on another slave's arp_queue; the packet reaches teql_master_xmit via sendto/udp_sendmsg → ip_finish_output2 → __dev_queue_xmit on teql0, not via a remote protocol field.
- AC:LAttack complexity, low
- The attacker chooses the slaves, sends on teql0 so teql_master_xmit() leaves skb->dev on a failed ndo_start_xmit/netif_xmit_frozen_or_stopped slave, then teql_resolve()/neigh_event_send() queues that skb for an unresolved neighbour, then issues RTM_DELLINK; flood_packet plus an unanswered ARP destination make this repeatable without third-party timing.
- PR:LPrivileges required, low
- RTM_NEWLINK, RTM_NEWQDISC (tc_modify_qdisc → teql_qdisc_init) and the freeing RTM_DELLINK all go through rtnetlink_rcv_msg(), which requires netlink_net_capable(skb, CAP_NET_ADMIN) against sock_net(skb->sk)->user_ns; unshare -Urn grants that namespaced capability without init-namespace root.
- UI:NUser interaction, none
- The attacker alone creates the slaves, grafts the teql0 qdisc, injects packets into teql_master_xmit(), and deletes the stale skb->dev slave with RTM_DELLINK; no other user must open a file, mount a volume, or otherwise act.
- S:UScope, unchanged
- The freed object is a kernel net_device from alloc_netdev_mqs()/rtnl_newlink, used later on the same host via skb->dev in __icmp_send() or dev_queue_xmit(); this is in-kernel memory corruption, not a VM, IOMMU, or hypervisor boundary crossing.
- C:HConfidentiality impact, high
- KASAN reports a slab-use-after-free read of the freed net_device in __icmp_send() (skb_in->dev->flags) from arp_error_report(); the same dangling skb->dev is consumed by neigh_direct_output() → dev_queue_xmit(), and reclaim of that slab object yields an arbitrary kernel read.
- I:HIntegrity impact, high
- Once the neighbour resolves, neigh_update_process_arp_queue() calls neigh_direct_output() → dev_queue_xmit() on the dangling skb->dev, so a reclaimed net_device's netdev_ops (ndo_start_xmit) become attacker-controlled, giving an arbitrary kernel write and control-flow hijack.
- A:HAvailability impact, high
- The reported path is neigh_timer_handler() → neigh_invalidate() → arp_error_report() → ipv4_link_failure() → __icmp_send() hitting a KASAN slab-use-after-free of the deleted slave net_device, which oopses/panics the kernel even without further exploitation.