Live › vulnerability › CVE-2026-99264
In the Linux kernel's io_uring receive path, a partially completed receive could be retried on ring buffers that were not fully committed, so another request may be given memory the retried receive still writes to. The result is that buffer contents can be overwritten and data from one request may be corrupted or mixed with another's.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 12:20 UTC. All times on this page are UTC.
Systems running a Linux kernel with io_uring receive operations that use incremental provided buffer rings or multi-buffer bundles are the ones at risk. The sources do not list affected kernel versions, and systems that do not use io_uring receives with these buffer types are not described as exposed.
No product ranges from the sources yet.
uname -r and compare it against the fixed kernel releases in the sources.Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
io_uring/net: don't retry recv on uncommitted buffers
Commit 41b70df5b38b ("io_uring/net: commit partial buffers on retry") commits ring provided buffers when a receive is going to be retried after a partial transfer, so that another request using the same buffer group can't be handed the memory the first one keeps receiving into. It commits the number of bytes received so far. That does the job for a single buffer which is consumed as a whole, but the request hangs on to all it has mapped:
In both cases the next receive with that buffer group gets memory that the retried request is still going to write to, and whoever comes last overwrites the data of the other. What the retry fills isn't committed at all, as the buffer list isn't known any more at that point. So the kernel hands it out again later on, while the CQE tells the application that it was used, and for an incremental buffer that it is done with.
The remainder can't be committed in advance: if the request ends up receiving less, there is no way to tell the application that more was consumed than the CQE accounts for. Complete the request with what it has got instead of retrying it. MSG_WAITALL is no longer honoured for receives into incremental buffers or multi buffer bundles, they can return a short count, with the request marked as failed like for other short MSG_WAITALL transfers.
This page as .md · .json · in your agent: get_signal("CVE-2026-99264")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.