CVE-2026-98233 in Linuxinfo

Summary

by MITRE • 10/06/2026

In the Linux kernel, the following vulnerability has been resolved:

net/packet: clear RX owner on VNET header error

Commit 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition") added rx_owner_map and made tpacket_rcv() 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 TPACKET_V2 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. TPACKET_V3 already clears its block state here.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 10/06/2026

The Linux kernel networking subsystem contains a specific vulnerability within the PACKET socket implementation that affects how virtual network header conversions are handled during packet reception. This issue stems from commit 61fad6816fc1, which was originally introduced to address a producer race condition by implementing an rx_owner_map mechanism. The core technical flaw lies in the tpacket_rcv function, where the kernel claims ownership of a ring slot for version one or two TPACKET rings before attempting to convert the virtio-net header. While this pre-claiming strategy is effective for preventing race conditions under normal circumstances, it introduces a critical state management error when the subsequent header conversion fails due to unsupported packet characteristics.

Specifically, if an incoming UDP Generic Segmentation Offload GSO packet arrives that cannot be successfully converted by the virtio-net driver logic, the kernel enters its drop path without properly releasing the previously claimed slot ownership. In standard operation with larger rings containing multiple slots, this might result in a minor resource leak or temporary unavailability of one buffer descriptor. However, in environments utilizing a minimal configuration such as a one-frame TPACKET_V2 ring, the consequences are severe and immediate. The single available slot remains marked as owned by the kernel even after the packet is dropped, effectively locking the entire receive queue. This state corruption causes the system to drop not only the invalid GSO packet but also any subsequent valid packets that arrive while the slot remains erroneously claimed, leading to a complete denial of service for network traffic on that specific socket interface.

From an industry standards perspective, this vulnerability aligns with CWE-401 Missing Release of Resource after Effective Lifetime and CWE-756 Missing Correct Access Control. The failure to clear the ownership bit represents a resource management error where system resources are not released appropriately following an abnormal execution path. In terms of attack vectors, while this is primarily a stability issue rather than a direct exploitation vector for privilege escalation or remote code execution, it can be leveraged in denial-of-service scenarios by flooding the interface with unsupported GSO packets to exhaust ring buffers and disrupt network connectivity. This behavior maps loosely to ATT&CK technique T1498 Network Denial of Service, specifically through resource exhaustion via malformed or unexpected traffic patterns that trigger internal kernel state corruption.

The resolution involves modifying the error handling path within tpacket_rcv to explicitly clear the ownership bit when virtio-net header conversion fails. This ensures parity with the existing behavior in TPACKET_V3 rings, which already correctly manage block states during similar failure scenarios. By restoring proper resource release semantics on this specific error branch, the kernel prevents the permanent locking of ring slots and maintains network stack stability under high-load or mixed-protocol conditions. Administrators should ensure that their Linux kernels are updated to include this fix, particularly in virtualized environments where virtio-net drivers are heavily utilized and GSO features are enabled by default for performance optimization.

Responsible

Linux

Reservation

09/25/2026

Disclosure

10/06/2026

Moderation

accepted

EPSS

0.00220

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!