SEC.co
Emergency
MEDIUM 5.5

CVE-2026-46315: Linux Kernel io_uring Memory Leak via WAITID Operation

A vulnerability in the Linux kernel's io_uring subsystem can leak uninitialized kernel memory to userspace when using the IOURING_OP_WAITID operation. When a wait operation completes without reporting child process events, the kernel fails to zero-initialize its result buffer before copying it to user applications, exposing stale data that was previously stored in the same kernel memory. This is a local information disclosure issue affecting users who can invoke io_uring operations on systems where they have access.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
—
Affected products
5 configuration(s)
Published / Modified
2026-06-09 / 2026-07-08

NVD description (verbatim)

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.

4 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-46315 is a use-after-free variant in the io_uring WAITID operation pathway. The struct io_waitid::info field, which holds result data copied to userspace via siginfo, is not initialized during the request prep phase. The underlying wait code may return without populating wo_info when no child events are pending. The io_waitid_finish() function then blindly copies iw->info to userspace, leaking kernel memory contents from the reused io_kiocb command storage. The fix initializes info to zero during prep, matching the behavior of the traditional waitid(2) syscall which uses zero-initialized struct waitid_info.

Business impact

This vulnerability enables local attackers to read kernel memory without authentication, potentially exposing sensitive data such as cryptographic keys, process identifiers, memory addresses useful for ASLR bypass, or other kernel state. The impact is limited to local access and does not enable privilege escalation or system compromise by itself, but the leaked information could facilitate further attacks. Organizations running multi-tenant or untrusted-workload systems on Linux are at higher risk.

Affected systems

The vulnerability affects the Linux kernel across multiple versions. Verify the specific kernel versions and distributions affected against your vendor's security advisory. Kernel subsystems with CONFIG_IO_URING enabled are vulnerable when the IOURING_OP_WAITID operation is available and invoked by unprivileged users.

Exploitability

Exploitation requires local access and the ability to invoke io_uring syscalls (requires CAP_SYS_RESOURCE or unrestricted io_uring access depending on kernel configuration). An unprivileged user can repeatedly invoke IOURING_OP_WAITID to leak kernel memory in small chunks. The operation is straightforward and does not require special timing or race conditions; any leak is deterministic once the operation completes without a child event. CVSS 5.5 reflects local-only attack vector and availability impact, with no code execution or elevation.

Remediation

Apply the kernel patch that initializes the io_waitid::info field to zero during the request prep phase. This ensures leaked memory is zeroed regardless of whether the underlying wait operation populates the result. Verify the patched kernel version against your vendor's advisory before deployment. If immediate patching is not feasible, restrict io_uring access via seccomp or AppArmor profiles on systems handling sensitive workloads.

Patch guidance

Consult your Linux distribution's security advisory for the patched kernel version. Patch releases typically include backports to stable and long-term support branches. After patching, reboot systems to ensure the new kernel is loaded. Test in a non-production environment first, particularly on systems with custom kernel configurations. If you build your own kernel, apply the upstream fix from the Linux kernel repository and recompile.

Detection guidance

Monitor system logs for unusual io_uring syscall activity, especially repeated IOURING_OP_WAITID calls. Enable audit rules to log io_uring operations if they are not normally used in your environment (auditctl -a exit,always -F arch=x86_64 -S io_uring_setup). Kernel memory leak detection tools may help identify abnormal memory access patterns. Verify kernel version and CONFIG_IO_URING status on deployed systems to prioritize scanning.

Why prioritize this

Prioritize patching for systems where untrusted local users can invoke io_uring (including container environments and multi-tenant cloud platforms). The medium CVSS score reflects limited attack surface (local only) but the information disclosure risk is real. Systems with strict local access controls or those that disable io_uring entirely are lower priority. Federated or high-security environments should patch sooner due to the memory leak surface.

Risk score, explained

CVSS 5.5 (Medium) is assigned because the vulnerability requires local access (AV:L), does not require special privileges (PR:L), and is not user-interaction dependent. The availability impact (A:H) reflects potential denial-of-service through resource exhaustion from repeated leaks, though the primary concern is confidentiality. No integrity or active availability impact on the system itself is expected from exploitation.

Frequently asked questions

Does this vulnerability allow privilege escalation?

No. The vulnerability is a local information disclosure that leaks kernel memory. While leaked data could theoretically assist in constructing subsequent exploits (e.g., ASLR bypass), this vulnerability alone does not elevate privileges or execute code.

What is io_uring and who uses it?

io_uring is a high-performance asynchronous I/O interface in the Linux kernel. It is used by applications requiring low-latency I/O such as databases, web servers, and storage systems. Not all applications use io_uring, so the attack surface depends on whether io_uring is enabled and accessible on your system.

Can this be exploited remotely?

No. The vulnerability requires local access to the system and the ability to invoke io_uring syscalls. Remote attackers cannot exploit this directly, though a prior compromise granting local access could enable it.

What should I do if I cannot patch immediately?

Restrict io_uring access using seccomp filters or AppArmor/SELinux policies to block the io_uring_setup syscall for untrusted processes. Disable CONFIG_IO_URING at build time if io_uring is not required. Monitor local user activity for unusual syscall patterns. Plan a patching window as soon as feasible.

This analysis is based on the published vulnerability description and CVSS assessment as of the modification date. Actual impact and patch timelines vary by Linux distribution and vendor. Consult your vendor's security advisory for specific affected versions and patch availability. This document does not constitute professional security advice; organizations should conduct their own risk assessment and testing before deployment. No exploit code or weaponized proof-of-concept is provided or recommended. Source: NVD (public-domain), retrieved 2026-07-16. Analysis generated by SEC.co (claude-haiku-4-5).

Affected vendors

linux

Related vulnerabilities