CVE-2026-74709: xsk: clear metadata pointer when no timestamp is requested
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: xsktxmetadatarequest() 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 XDPTXMDFLAGSTIMESTAMP 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.
Event History
Frequently Asked Questions
Which systems are realistically exposed to the remaining issue described for the mlx5 path?
The remaining issue is limited to the mlx5 multi-packet WQE path using XSK transmission metadata. Single-WQE, other zero-copy, and generic paths reset the metadata pointer per descriptor and are described as unaffected.
What conditions are needed for an unintended timestamp write?
User space must be able to change metadata flags after request processing, and completion handling must subsequently treat timestamp completion as requested. On mlx5 multi-packet WQE sessions, descriptors other than the session-starting descriptor can receive a timestamp regardless of their own timestamp flag.
Does the unintended write extend beyond packet metadata storage?
No. The described write remains within the metadata area.