Look up another CVE · open CVE-2026-74742 in the interactive tracker
CVE-2026-74742
veth: fix queue index used to wake the peer txq in veth_poll
Published 2026-08-26 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-74742 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.105-1 | Update the kernel and reboot. Fixed in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
veth_poll() derives the index of the peer TX queue to wake from rq->xdp_rxq.queue_index. That field is only initialized by xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an XDP program is attached. On the plain GRO/NAPI path (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so queue_index stays 0 for every queue, as priv->rq is zero-allocated. So in a multi-queue setup with GRO enabled and no XDP program attached, every NAPI instance looks at the peer's TX queue 0. If veth_xmit() stops peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing ever wakes it again: the poller draining queue 1 wakes queue 0 instead. veth implements no ndo_tx_timeout, so the netdev watchdog does not kick in either, and the queue stays stopped indefinitely. Derive the index from the position of the rq within priv->rq instead, which is correct regardless of whether XDP was ever enabled. Scripts to reproduce the stall are available at https://github.com/netoptimizer/veth-backpressure-performance-testing
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.
drivers/net/veth.c
- What this is
- NETWORKING DRIVERSMAINTAINERS section matched on drivers/net/ · netdev@vger.kernel.org · Maintained
- Kernel module
- veth
Check it on the machine
grep -w CONFIG_VETH /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 vethPrints 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_VETH
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-08-26 (2 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.46%, higher than 38.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.12.61 | 6.12.105 | b662a1fb4f3a |
| 6.16 | 6.18.46 | 73f8dd22b1e5 |
| 6.16 | 7.1.10 | 90bb11fb29d3 |
| 6.16 | 7.2 | 60db47f02bfa |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | 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:NAttack vector, network
- Remote packets routed, NATed, or bridged into a suitably configured container veth reach veth_xmit() and veth_poll() through normal netdev transmit and NAPI softirq paths; no local syscall or physical access is required.
- AC:LAttack complexity, low
- Sustained multi-flow traffic can deterministically fill the ptr_ring on a non-zero RX queue and drive its NAPI poller; waking queue 0 instead of the stopped queue is a logic bug, not a race or layout-dependent condition the attacker cannot control.
- PR:NPrivileges required, none
- Multi-queue veth, GRO, and a non-noqueue qdisc are infrastructure prerequisites, not attacker privileges; forwarded packets traverse veth_xmit/veth_poll with no capability or authentication check, as with CVE-2025-68232 in the same backpressure code.
- UI:NUser interaction, none
- Exploitation requires only attacker-generated network traffic to drive backpressure on the veth pair; no victim action such as mounting filesystems or opening files is necessary.
- S:UScope, unchanged
- The defect leaves transmit queues in DRV_XOFF within the host kernel veth driver and does not cross VM, IOMMU, or sandbox security boundaries.
- C:NConfidentiality impact, none
- The bug only mis-associates NAPI poll instances with peer TX queue indices during wakeup; there is no out-of-bounds access, use-after-free, or other memory read primitive.
- I:NIntegrity impact, none
- No memory corruption, arbitrary write, packet tampering, or control-flow influence occurs; the failure is limited to incorrect queue state management on the transmit path.
- A:HAvailability impact, high
- When a non-zero peer TX queue is stopped for a full ptr_ring, veth_poll() never wakes it again and veth has no ndo_tx_timeout recovery, causing an indefinite transmit stall and persistent loss of connectivity on affected queues.