CVE-2026-99282
net/sched: sch_teql: fix use-after-free on lower qdisc drop
What happened?
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_teql: fix use-after-free on lower qdisc drop
The issue: teql_master_xmit() tests the slave's ndo_start_xmit() return value against NETDEV_TX_OK alone. A slave that consumes the skb but returns an error code (rc < NET_XMIT_MASK, e.g. NET_XMIT_DROP) is treated as if the skb were still owned, so the loop restores skb->dev and calls __skb_pull() on it. A VLAN slave returns the result of dev_queue_xmit() from its ndo_start_xmit() (propagated since cbbef5e18307), and when the lower qdisc drops the packet that value is NET_XMIT_DROP after the skb has been freed, giving a use-after-free in teql_master_xmit().
The Fix: test for consumption with dev_xmit_complete(), which accepts NETDEV_TX_OK and every rc < NET_XMIT_MASK, matching other callers that need to distinguish consumed results from busy. Only NETDEV_TX_OK keeps the packet counted in tx_packets/tx_bytes and advances the slave; a consumed result that is neither a success nor NET_XMIT_CN ends the attempt and is charged to tx_dropped, so lower-qdisc drops are no longer reported as good transmits. NET_XMIT_CN is counted like success because it can accompany acceptance of the current packet: pfifo_head_drop drops the old head, enqueues the current skb and returns NET_XMIT_CN.
Conditions to recreate the bug: With CONFIG_NET_SCH_TEQL, CONFIG_VLAN_8021Q and CONFIG_DUMMY enabled, add lkrdummy0 (dummy) and lkrvlan0 (VLAN id 37 on lkrdummy0); set a pfifo limit 0 root on lkrdummy0 and a teql0 root on lkrvlan0; bring teql0 up with an address and send one UDP packet to it. The VLAN xmit returns NET_XMIT_DROP from the lower qdisc while holding a freed skb.
Affected software and versions
| Software | Version information | Fixed version |
|---|---|---|
| LinuxLinux | affected: 572a9d7b6fc7f20f573664063324c086be310c42 to < 8d5f768780e26cb82c389219ae7fdb1cd7255421; affected: 572a9d7b6fc7f20f573664063324c086be310c42 to < fc55d92ae6a4b2e7d062cad6d4c67f6b061d9cde; affected: 572a9d7b6fc7f20f573664063324c086be310c42 to < 2702ae318630787c640ec0d0403ffd9d95c43e9e; affected: 572a9d7b6fc7f20f573664063324c086be310c42 to < 782d6bb8f9b8e9d8591181662222bf74cd3ecf79 | See vendor advisory |
| LinuxLinux | affected: 2.6.33; unaffected: 0 to < 2.6.33; unaffected: 6.12.117 to ≤ 6.12.*; unaffected: 6.18.61 to ≤ 6.18.*; unaffected: 7.3.2 to ≤ 7.3.*; unaffected: 7.4-rc1 to ≤ * | See vendor advisory |
Version information comes from the source record and can include unaffected products and exceptions. Distribution packages may contain backported fixes: an older upstream version alone does not prove a server is affected.
Is it being exploited?
This CVE was not listed in the CISA catalogue at our last retrieval. This does not establish that exploitation is absent.
How to respond
- Confirm the product, installed package version, and any configuration requirements in the vendor advisory.
- Follow the vendor’s remediation or workaround guidance in the references below. Structured fixed-version data is unavailable here; the publisher’s description may include a fix or workaround.
- Restart affected services if required, then verify the running version. Known exploitation may warrant investigation as well as patching.
Sources and remediation references
- https://www.cve.org/CVERecord?id=CVE-2026-99282
- https://git.kernel.org/stable/c/8d5f768780e26cb82c389219ae7fdb1cd7255421
- https://git.kernel.org/stable/c/fc55d92ae6a4b2e7d062cad6d4c67f6b061d9cde
- https://git.kernel.org/stable/c/2702ae318630787c640ec0d0403ffd9d95c43e9e
- https://git.kernel.org/stable/c/782d6bb8f9b8e9d8591181662222bf74cd3ecf79