CVE-2026-74684: net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp()
In the Linux kernel, the following vulnerability has been resolved:
net: tap: set skb->dev before parsing virtio net header in tapgetuserxdp()
The commit 4f61f133f354 ("net: tap: NULL pointer derefence in devparseheaderprotocol when skb->dev is null") fixed a crash in tapgetuser() by assigning skb->dev before calling tunvnethdrtoskb(). This is required because virtionethdrtoskb() may invoke devparseheaderprotocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur.
However, tapgetuserxdp() 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, tunvnethdrtoskb() can reach devparseheaderprotocol() while skb->dev is still NULL, resulting in a crash.
Fix this by looking up the tap device and assigning skb->dev before calling tunvnethdrtoskb(), matching the ordering already used in tapgetuser(). Preserve the existing RCU read-side critical section across devqueuexmit().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Apply the referenced kernel fix to address the NULL pointer dereference in dev_parse_header_protocol() triggered when tap_get_user_xdp()/tap_get_user parse the virtio-net header before skb->dev is assigned.
Event History
Frequently Asked Questions
What conditions are required to trigger the crash?
The vhost TX path must pass an XDP buffer containing a GSO virtio-net header with its protocol deliberately set to zero. Under those conditions, parsing can reach dev_parse_header_protocol() before skb->dev has been assigned.
What is the practical impact of successful triggering?
The affected path can dereference a NULL skb->dev pointer and crash the kernel. The provided information describes a denial-of-service condition; it does not establish data disclosure or code execution.
Which component or traffic path should be prioritized for triage?
Prioritize systems using TAP networking through the vhost TX/XDP path, particularly where GSO virtio-net headers can be supplied with a zero protocol field. The issue is specifically in tap_get_user_xdp(), not the already corrected tap_get_user() path.
What change resolves the issue?
The fix looks up the TAP device and assigns skb->dev before calling tun_vnet_hdr_to_skb() in tap_get_user_xdp(). This prevents virtio-net header parsing from invoking dev_parse_header_protocol() with a NULL device pointer.