CVE-2026-98233: net/packet: clear RX owner on VNET header error
In the Linux kernel, the following vulnerability has been resolved:
net/packet: clear RX owner on VNET header error
Commit 61fad6816fc1 ("net/packet: tpacketrcv: avoid a producer race condition") added rxownermap and made tpacketrcv() claim a V1 or V2 ring slot before converting the virtio-net header. If the conversion fails, the drop path leaves the slot claimed.
With a one-frame TPACKETV2 ring, an unsupported UDP GSO packet leaves the only slot unavailable, so the ring also drops the next valid packet.
Clear the ownership bit on this error path. TPACKETV3 already clears its block state here.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In tpacket_rcv(), clear the RX ownership bit for the V1 or V2 ring slot when virtio-net header conversion fails, so the slot is not left claimed.
Event History
Frequently Asked Questions
Which packet-capture setups are affected?
The issue affects TPACKET_V2 packet rings that use virtio-net header conversion. The documented failure case requires a one-frame ring; TPACKET_V3 already clears its block state on this error path.
What traffic condition triggers the packet-loss behavior?
An unsupported UDP GSO packet must reach the affected TPACKET_V2 ring and fail virtio-net header conversion. That packet can leave the claimed ring slot unavailable, causing the next otherwise valid packet to be dropped when the ring has only one frame.
How can I identify a likely affected deployment?
Look for packet sockets using a one-frame TPACKET_V2 ring with virtio-net header processing, where an unsupported UDP GSO packet is followed by an unexpected drop of a valid packet. The observed behavior is loss of the next packet after the conversion error.