Cloudanix VulnDB

CVE-2026-99264

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's fast networking interface can let local programs accidentally overwrite each other's network data, potentially causing crashes or incorrect results.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in io_uring receive path allows reuse of partially committed ring buffers on retry after partial transfers, causing subsequent receives to overwrite data still held by the retried request.

Why it matters to the business

Local processes can corrupt network receive data or cause application crashes and unexpected behavior in high-performance I/O workloads that rely on io_uring, increasing risk of data integrity issues on affected Linux systems.

How an attack unfolds

An attacker with local access crafts a program that posts incremental or bundled buffers via io_uring and triggers partial receives that force retries; the kernel re-issues the same buffer memory to a new request while the original request continues writing, allowing the attacker to observe or influence overwritten data.

How to fix it

Update the Linux kernel to a version containing commit 41b70df5b38b and the follow-up fix that completes requests with partial data instead of retrying on uncommitted incremental or bundled buffers.

How to confirm the fix worked

Verify the running kernel contains the referenced commit or later; test io_uring receive paths with incremental buffers and MSG_WAITALL to confirm short transfers no longer trigger buffer reuse.

Typical attack path

  1. Obtain local unprivileged access on a vulnerable Linux system
  2. Map an io_uring instance and register a buffer ring using incremental or multi-buffer mode
  3. Issue receive requests with MSG_WAITALL that receive only a partial amount of data
  4. Force retry conditions while another request consumes the same buffer group
  5. Observe or manipulate the resulting data corruption or CQE inconsistencies

How to detect it

Review kernel logs for io_uring warnings related to buffer rings, audit io_uring CQE sequences for short MSG_WAITALL receives on incremental buffers, and inspect application behavior for unexpected data corruption after partial network receives.

What your security team should do

  • Prioritize kernel updates on systems running io_uring workloads within the next patching cycle
  • Monitor upstream stable kernel releases for the backported fix
  • Restrict untrusted local code execution on systems where io_uring is enabled until patched

The record

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: - For a buffer ring with IOU_PBUF_RING_INC only these bytes are consumed. The rest of the buffer stays at the head of the ring. - For a bundle only the buffers which hold these bytes are consumed, the others that were peeked stay in the ring. 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.

Affected packages

Ecosystem Package Introduced Fixed