Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Stale kernel memory disclosed to userspace warrants C:H; no crash or write primitive is described, so A:N and I:N; PR:L reflects required local io_uring account access.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
5DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
io_uring/waitid: clear waitid info before copying it to userspace
IORING_OP_WAITID stores its result fields in struct io_waitid::info and later copies them to userspace siginfo. The prep path initializes the request arguments, but it does not initialize info itself.
If the wait operation completes without reporting a child event, the common wait code can return without writing wo_info. In that case io_waitid_finish() still copies iw->info to userspace, exposing stale bytes from the reused io_kiocb command storage.
Clear the result storage during prep so the io_uring path matches the regular waitid syscall, which uses a zero-initialized struct waitid_info.
AnalysisAI
Stale kernel memory disclosure in the Linux kernel's io_uring IORING_OP_WAITID operation allows a local low-privileged user to read arbitrary bytes from reused io_kiocb command storage via the userspace siginfo output buffer. The io_uring prep path for waitid requests fails to zero-initialize the io_waitid::info result field, meaning that when a wait completes without a child event the kernel copies whatever bytes happen to occupy that slab slot into the caller's siginfo_t. No public exploit has been identified at time of analysis; EPSS at 0.02% (5th percentile) reflects low current exploitation probability.
Technical ContextAI
The vulnerability lives in the Linux kernel's io_uring subsystem (io_uring/waitid.c), specifically in the IORING_OP_WAITID code path, which wraps the waitid(2) syscall for asynchronous process state monitoring. io_uring, introduced in Linux 5.1, uses a shared ring buffer between kernel and userspace and reuses io_kiocb slab objects across requests. The struct io_waitid embeds an info field of type struct waitid_info that is supposed to receive wait result data, but the prep function does not initialize it to zero. The regular waitid(2) syscall uses a zero-initialized struct waitid_info on the stack, so this code path diverged from the safe baseline. The introduced commit f31ecf671ddc498f20219453395794ff2383e06b is the origin of the flaw. When the underlying wait returns without reporting a child event (e.g., WNOHANG with no matching child state), the common wait code returns without populating wo_info, and io_waitid_finish() then copies the uninitialized iw->info bytes directly to userspace. No CWE was assigned by NVD, but this is structurally a CWE-908 (Use of Uninitialized Resource) leading to kernel memory disclosure.
RemediationAI
Update to a patched Linux kernel stable release: 6.12.92 or later, 6.18.34 or later, or 7.0.11 or later. The upstream fixes are available at https://git.kernel.org/stable/c/954518e5a4a5efc5033253f6e36fc7b9f98363a3, https://git.kernel.org/stable/c/b737c6612c60c23b40a9f31749b99e6f61943847, https://git.kernel.org/stable/c/4d2a0de611ab60d02fc768ae0cd5918b16bd5474, and https://git.kernel.org/stable/c/93d93f5f8da791e98159795c6ef683f45bd95d13. If patching is not immediately feasible, restrict io_uring access for unprivileged users via 'sysctl kernel.io_uring_disabled=1' (limits to privileged processes) or '=2' (disables entirely); this sysctl is available from Linux 5.15 onward, though setting it to 2 will break applications that rely on io_uring for I/O performance such as storage-intensive databases and high-throughput proxies. Container environments can additionally restrict io_uring via seccomp policies denying io_uring_enter(2), or via AppArmor/SELinux io_uring deny rules, with the same application compatibility caveat.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-35373
GHSA-3xr6-r26v-fpqm