EUVD-2026-115789
GHSA-q4wp-8vpq-9rg3
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLocal access to host running io_uring workload
-
DeliveryIssue recv on incremental/bundle provided-buffer ring
-
ExploitInduce partial transfer forcing buffer retry
-
ExecutionKernel reuses uncommitted buffer for next receive
-
ImpactCross-request data leak or corruption
Vulnerability Assessment
| Exploitation Conditions | Requires a local process using io_uring with ring-provided buffers configured either for incremental consumption (IOU_PBUF_RING_INC) or for multi-buffer bundle receives, AND a receive that undergoes a partial transfer and is retried (e.g. under MSG_WAITALL semantics). Only then does the kernel hand buffer memory still being written by the retried request to the next receive in the same buffer group, causing cross-request leak/overwrite. LIMITING FACTORS: not exploitable against default configurations - most applications do not use these specific io_uring buffer modes; exploitation is local only (AV:L), needs a low-privileged local process that can drive such io_uring receives (PR:L), and is confined to recent affected kernels (6.6.103+, 6.12.44-6.12.115, 6.15.11-6.16, 6.16.2-6.17 branches per EUVD); no remote or unauthenticated path exists. |
| Impact | The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.8 High) correctly frames this as a LOCAL vulnerability: it is not remotely reachable despite affecting network-receive code, because the flaw is in how the local kernel io_uring subsystem manages ring-provided buffers, and triggering it requires a local process to issue io_uring receives using specific buffer modes (PR:L reflects that a local, low-privileged process suffices). No EPSS score, SSVC exploitation/automatable values, or KEV entry were supplied, and no proof-of-concept or exploit reference is present - only patch commits. Exploitation status: no public exploit identified at time of analysis. The vuln.today Decision label is 'this_week', which aligns with a serious but not emergency local-privilege/data-integrity bug rather than an actively exploited remote flaw. The practical risk is bounded: the vulnerable path only activates for applications that use IOU_PBUF_RING_INC incremental buffer rings or multi-buffer bundle receives and that experience a partial transfer requiring retry, which is a non-default, relatively recent io_uring usage pattern. This is a legitimate correctness/data-safety priority for systems running such io_uring workloads, but it is not a high-CVSS-but-universally-exploitable issue - the local-only vector and the specialized configuration requirement substantially narrow real-world exposure versus the raw 7.8 score. |
| Exploit ScenarioDerived | A local process on an affected kernel uses an io_uring provided-buffer ring configured with incremental buffers (IOU_PBUF_RING_INC) or bundle receives and issues a receive that completes only partially, forcing a retry. The retried request keeps writing into buffer memory that the kernel has already handed to the next receive in the same buffer group, so data from one request is leaked into or overwrites another request's buffer while the CQE falsely reports the buffer as consumed. No public exploit code or PoC was provided; realistic abuse requires local access and an application driving these specific io_uring buffer modes. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 03, 2026
Cross-request buffer reuse in the Linux kernel's io_uring networking receive path allows a local process to read or overwrite data belonging to another receive request when an application uses incremental ring-provided buffers (IOU_PBUF_RING_INC) or multi-buffer bundles together with a receive that is partially satisfied and then retried, typically under MSG_WAITALL semantics. Affected kernels span the 6.6.103+, 6.12.44 through 6.12.115, 6.15.11 through 6.16, and 6.16.2 through 6.17 branches per EUVD, with vendor fixes released in 6.12.115, 6.18.60 and 7.2.14. The flaw is local only, requires a low-privileged process that drives these specific io_uring buffer modes, and no public exploit has been identified at time of analysis; exploitation also requires a partial transfer plus retry, so it is not reachable against typical default application configurations.
RemediationAI
Apply the vendor-released stable updates: Linux 6.12.115, 6.18.60 or 7.2.14 depending on branch, which carry the upstream fixes 21cb1770a56a51266ab96d4ed2a3b6979db59694, fc8506eea4498ecba26ef8bf6dbbd74af3dc891d, 97b8dc36ba3cb176b74a7929140aeaeb40d5cdc0 and 8444de681a179e41a4eb92d5bbe770a0677074a6 (https://git.kernel.org/stable/c/21cb1770a56a51266ab96d4ed2a3b6979db59694, https://git.kernel.org/stable/c/fc8506eea4498ecba26ef8bf6dbbd74af3dc891d, https://git.kernel.org/stable/c/97b8dc36ba3cb176b74a7929140aeaeb40d5cdc0, https://git.kernel.org/stable/c/8444de681a179e41a4eb92d5bbe770a0677074a6); note the fix is behavioural as well as defensive, so receives into incremental buffers or multi-buffer bundles may now return short counts with the request marked failed instead of being retried to satisfy MSG_WAITALL, and applications relying on full-length MSG_WAITALL receives in those modes must handle short completions. Where kernels cannot be updated promptly, the exploitable precondition can be removed at the application layer by not using IOU_PBUF_RING_INC incremental buffer rings or multi-buffer bundle receives for io_uring networking, or by not issuing MSG_WAITALL receives into them - the trade-off is losing incremental buffer recycling and recvmsg batching, i.e. more per-request buffer provisioning and possibly more syscalls. Restricting io_uring access via seccomp for untrusted local workloads also removes the attack surface, at the cost of breaking applications that legitimately depend on io_uring; there is no network-level mitigation, since the defect is local and confined to recent kernels in the affected branches.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
io_uring's net receive support can draw destination memory from user-registered buffer rings rather than a single supplied buffer. In incremental mode (IOU_PBUF_RING_INC) a ring buffer is consumed only by the number of bytes actually received, leaving the remainder at the head of the ring for the next receive; in multi-buffer bundle mode only the buffers that hold the received bytes are consumed, while the rest that were peeked remain in the ring. Commit 41b70df5b38b ("io_uring/net: commit partial buffers on retry") tried to prevent a second request from being handed the same memory by committing the byte count received so far before a retry. That is sufficient only when a buffer is consumed as a whole: for incremental rings and bundles the request still holds mappings over the unconsumed remainder, and the bytes written by the retry are never committed at all because the buffer list is no longer known at that point. The kernel therefore hands that memory to a later receive in the same buffer group while the retried request is still writing into it, producing a cross-request overwrite (last writer wins) and a matching information-disclosure path, while the completion queue entry tells the application the buffer was used and, for an incremental buffer, finished. The remainder cannot be committed in advance because a short receive would force the kernel to report more consumption than the CQE accounts for, so the upstream fix completes the request with what it has instead of retrying it, and MSG_WAITALL is no longer honoured for receives into incremental buffers or multi-buffer bundles - such receives may return a short count with the request marked failed, as with other short MSG_WAITALL transfers. The root-cause class is a buffer-lifetime/ownership error in the kernel's provided-buffer bookkeeping; no CWE identifier was assigned in the supplied data, and the trigger is precisely the partial-transfer-then-retry sequence rather than any generic timing or memory-corruption primitive.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local unprivileged process driving io_uring receives (AV:L/PR:L); cross-request buffer reuse leaks and corrupts data (C:H/I:H); description shows no crash or resource exhaustion, so A:N.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
3DescriptionCVE.org
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.
Executive ViewAI
A high-severity vulnerability in the Linux kernel's io_uring networking receive path could allow a local low-privileged process to read or overwrite data from other receive requests, potentially leading to data leakage or integrity compromise. This affects servers and workloads that use advanced io_uring buffer features, meaning leadership should be concerned about potential cross-tenant data exposure in multi-tenant environments and the need to prioritize patching of affected systems.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB