CVE-2026-90086: xsk: honor XDP_TX_METADATA in zero-copy path
In the Linux kernel, the following vulnerability has been resolved:
xsk: honor XDPTXMETADATA in zero-copy path
The zero-copy path reads TX metadata whenever the UMEM has metadata space, even if the descriptor does not set XDPTXMETADATA. Pass descriptor options through the metadata helpers and ignore metadata unless the option is set.
This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs. Only the descriptor that starts a session passes through xsktxmetadatarequest() and configures offload state shared by the batch. Metadata on descriptors joining an open session is therefore not validated and does not configure its requested offloads. In addition, a non-NULL metadata pointer from such a descriptor is treated as a timestamp completion request even when XDPTXMDFLAGSTIMESTAMP is not set, so its metadata union can be overwritten with an unrequested timestamp. Fixing mixed metadata states within one MPWQE requires a separate change.
Affected Software
Event History
Frequently Asked Questions
When can incorrect TX metadata processing occur?
It can occur on the AF_XDP zero-copy transmit path when a UMEM provides metadata space but a transmitted descriptor does not set XDP_TX_METADATA. The affected path previously read metadata based on UMEM layout rather than the descriptor option.
Does this resolve all metadata handling issues for mlx5 MPWQEs?
No. The change does not fix existing per-WQE metadata handling for mlx5 MPWQEs, including mixed metadata states among descriptors in an open session.
What remains possible with mlx5 MPWQEs after this fix?
For descriptors joining an already open MPWQE session, metadata is not validated and does not configure requested offloads. A non-NULL metadata pointer may also be interpreted as a timestamp completion request even when XDP_TXMD_FLAGS_TIMESTAMP is not set, potentially overwriting the metadata union with an unrequested timestamp.