CVE-2026-74709 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
xsk: clear metadata pointer when no timestamp is requested
User space can change metadata flags after request processing. Rereading them during completion can therefore make the kernel write a timestamp that was not requested when the packet was submitted.
Clear the metadata pointer during request processing unless timestamp completion is requested. Completion handling can then use the pointer itself instead of rereading the flags.
On the mlx5 multi-packet WQE path metadata is evaluated per batch: xsk_tx_metadata_request() runs only for the descriptor that starts a session, just like the checksum offload that is applied once through the shared WQE. Only that descriptor's pointer is reset, so completion handling can record a timestamp for the other descriptors of the session regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays inside the metadata area; the single-WQE, other zero-copy, and generic paths reset the pointer per descriptor and are unaffected.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel networking subsystem contains a vulnerability within the AF_XDP (AF_XSK) implementation that allows for unintended data writes due to improper handling of user-space metadata flags during packet transmission completion. This issue specifically affects scenarios where timestamping is requested via XDP_TXMD_FLAGS_TIMESTAMP, but the flag state can be modified by user space after the initial request processing phase has concluded. The core technical flaw lies in the kernel's reliance on re-reading these metadata flags at the time of completion rather than capturing and storing the intent during the submission phase. Because user-space applications have direct access to the memory regions mapped for XDP sockets, they can alter the flag values between the moment a packet descriptor is processed by the driver and the moment its transmission status is reported back through the completion queue. This race condition enables the kernel to write timestamp metadata into the designated buffer even when such data was not originally requested for that specific packet instance, leading to unauthorized memory writes within the user-space mapped region.
From an operational perspective, this vulnerability represents a violation of the principle of least privilege regarding memory access and state management. Although the write operation is constrained to remain within the allocated metadata area associated with the socket, it constitutes an out-of-band modification of data that should be immutable once submitted for processing. This behavior can lead to data corruption in applications relying on precise timestamping or strict adherence to requested metadata fields. Furthermore, if user-space code assumes that the absence of a request implies no write will occur, subsequent logic may misinterpret stale or unexpected values as valid timestamps, potentially causing application-level errors or incorrect network performance metrics. The vulnerability is particularly relevant in high-throughput environments where zero-copy networking paths are utilized to minimize latency and CPU overhead, making efficient but safe metadata handling critical for system stability.
The technical root cause is identified as a lack of atomicity between flag inspection and pointer management during the request processing stage. In standard single-WQE (Work Queue Element) operations and other generic zero-copy paths, the kernel resets the metadata pointer per descriptor immediately after evaluation, which effectively neutralizes subsequent user-space modifications to flags for that specific packet. However, in optimized multi-packet WQE implementations used by drivers such as Mellanox mlx5, metadata is evaluated on a batch basis rather than individually. In this architecture, xsk_tx_metadata_request() executes only for the descriptor initiating a session, similar to how checksum offload settings are applied once via shared work queue elements. Consequently, if the timestamp flag was set at submission but cleared by user space before completion processing, or vice versa in complex race conditions involving batched descriptors, the kernel may incorrectly apply metadata writes based on stale or altered state rather than the original request intent.
To mitigate this vulnerability, the fix involves clearing the metadata pointer during the initial request processing phase unless timestamp completion is explicitly requested for that specific descriptor session. By nullifying the pointer early in the pipeline, subsequent completion handling routines are forced to rely on the captured context of whether a timestamp was actually required at submission time rather than re-evaluating volatile flags from user space memory. This approach ensures that only descriptors with an active and verified request for timestamps will result in metadata writes during completion. For mlx5 multi-packet WQE paths, this change means resetting the pointer specifically for the session-starting descriptor to prevent timestamp recording for other descriptors in the batch unless they were individually flagged at submission time. Other execution paths such as single-WGE operations remain unaffected by this specific logic shift because they already operate on a per-descriptor basis with immediate pointer reset mechanisms that inherently isolate each packet's metadata handling from subsequent user-space modifications.
This vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition), as the flaw arises from unsynchronized access to shared memory flags between kernel processing threads and user-space applications. Additionally, it relates to CWE-787, Out-of-bounds Write, although in this specific instance, the write is bounded within the allocated metadata buffer rather than causing a general heap or stack overflow. The exploitation vector falls under ATT&CK technique T1059, Command and Scripting Interpreter, specifically through indirect manipulation of system resources via user-space applications interacting with kernel interfaces like AF_XDP. Defense in depth strategies should include strict validation of all XDP metadata flags at the point of submission rather than completion, ensuring that state changes by untrusted user space cannot influence kernel-side data generation logic. Regular updates to the Linux kernel and associated networking drivers are essential to maintain this security boundary, particularly for deployments utilizing high-performance network interfaces with multi-packet WQE capabilities where batch processing optimizations introduce unique race condition vectors not present in simpler single-descriptor implementations.