Look up another CVE · open CVE-2026-74684 in the interactive tracker
CVE-2026-74684
net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp()
Published 2026-08-22 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-74684 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-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
The commit 4f61f133f354 ("net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur. However, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash. Fix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit().
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/tap.c
- What this is
- TUN/TAP DRIVERMAINTAINERS section matched on drivers/net/tap.c · Maintained
- Kernel module
- tap
Check it on the machine
grep -w CONFIG_TAP /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 tapPrints 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_TAP
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-22 (2 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.15%, higher than 3.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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 |
|---|---|---|
| 5.12 | 6.12.105 | 15583b07fd69 |
| 5.12 | 6.18.45 | 8b444b126cd8 |
| 5.12 | 7.1.9 | 164c31ee252e |
| 5.12 | 7.2 | 3874892dd27d |
| 4.14.226 | 0 | 0 |
| 4.19.181 | 0 | 0 |
| 5.4.106 | 0 | 0 |
| 5.10.24 | 0 | 0 |
| 5.11.7 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-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
- A malicious KVM guest reaches tap_get_user_xdp() by kicking the virtio-net TX virtqueue; vhost_net handle_tx_copy batches XDP buffers and invokes tap_sendmsg(TUN_MSG_PTR), not via any host network packet-receive path.
- AC:LAttack complexity, low
- On typical QEMU/KVM vhost-net+tap/macvtap backends with TX batching enabled, a guest fully controls virtio-net GSO headers and Ethernet frames; sending GSO with ethertype 0 deterministically hits dev_parse_header_protocol() with skb->dev NULL without races.
- PR:NPrivileges required, none
- No host root or capabilities are required; a malicious cloud VM tenant only needs code execution inside a guest using virtio-net with a vhost-net tap backend, matching other guest-to-host virtio/KVM CNA scores.
- UI:NUser interaction, none
- No separate victim action is needed; the attacker submits crafted virtio-net TX descriptors from their own guest workload during normal VM operation without requiring host administrator interaction.
- S:CScope, changed
- Guest-supplied virtio-net TX data triggers a NULL pointer dereference in host tap_get_user_xdp(), panicking the physical host kernel and crossing the KVM guest-to-host virtualization security boundary.
- C:NConfidentiality impact, none
- The failure mode is a NULL pointer dereference at dev->header_ops with skb->dev unset; there is no demonstrated out-of-bounds read, use-after-free, or other memory corruption that could disclose host kernel data.
- I:NIntegrity impact, none
- No guest-controlled host memory write or control-flow hijack occurs; the host kernel oopses on the NULL dereference before any exploitable modification beyond the immediate crash.
- A:HAvailability impact, high
- The NULL pointer dereference in dev_parse_header_protocol() provokes a host kernel oops/panic in the vhost worker during guest virtio-net TX, denying availability of the hypervisor and all co-resident VMs.