CVE-2026-46315

What it actually does

This is a local information disclosure flaw in the Linux kernel io_uring implementation of IORING_OP_WAITID. The kernel stores waitid result data in an internal io_waitid::info structure and later copies that structure to userspace. Because the structure was not cleared during request preparation, a wait operation that completes without a child-event result can cause stale bytes from reused io_kiocb command storage to be copied back to the calling process. The impact is unintended disclosure of kernel or adjacent request-state memory contents to a local userspace process, not direct remote code execution or privilege escalation by itself.

Why it matters to the business

Systems running affected Linux kernel versions may allow a local user or compromised low-privilege process to read small amounts of unintended kernel-side data. While this vulnerability is not known to be exploited in the wild, is not in CISA KEV, and has a low EPSS score, it can still increase risk on multi-user servers, container hosts, build systems, shared compute platforms, and other environments where untrusted local workloads run. The main operational concern is that leaked data could help an attacker bypass defenses, gather sensitive runtime information, or support a later exploit chain.

How an attack unfolds

An attacker first needs local code execution on a vulnerable Linux system and access to io_uring functionality. They create io_uring requests using IORING_OP_WAITID and intentionally exercise a path where the wait operation completes without reporting a child event. Because the kernel-side result buffer was not initialized, the completion path may copy stale bytes from reused io_kiocb command storage into the userspace siginfo result buffer. The attacker can repeat this behavior to sample leaked bytes and analyze them for useful information, such as residual kernel request data or values that may assist with further exploitation. There is no indication from the provided data that public exploitation or ransomware use is occurring.

How to fix it

Apply a Linux kernel update that includes the fix to clear the io_uring waitid result storage during request preparation. Where vendor packages are used, upgrade to the fixed kernel release provided by the operating system or appliance vendor and reboot into the updated kernel. If immediate patching is not possible, reduce exposure by restricting untrusted local shell access, limiting execution of untrusted workloads, and considering temporary controls that restrict io_uring use where supported by the distribution or workload policy. Because no exact affected product list or fixed package versions were provided, use vendor advisories and kernel package changelogs to identify the corrected build for each platform.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the io_uring/waitid initialization fix, not merely that packages have been installed. Validate with kernel version and package metadata from the operating system vendor, then reboot if the old kernel is still active. Review vendor changelogs or source patches for a fix equivalent to clearing io_waitid::info before copying it to userspace. For high-assurance environments, run a regression test that exercises IORING_OP_WAITID completion paths without child-event results and confirms the returned siginfo data is zeroed rather than containing stale bytes.

Typical attack path

1. Obtain local execution on a Linux host running an affected kernel.
2. Confirm the process can use io_uring and submit IORING_OP_WAITID operations.
3. Trigger waitid requests that complete without a child-event result.
4. Receive a userspace siginfo buffer populated with uninitialized stale kernel-side data.
5. Repeat the operation to collect additional leaked bytes.
6. Analyze leaked data for sensitive values or information useful in a broader attack chain.

How to detect it

There are no reliable network indicators because exploitation requires local execution and involves normal kernel interfaces. To investigate possible prior exploitation, review endpoint telemetry, audit logs, and EDR process history for unusual locally executed binaries that interact heavily with io_uring and waitid behavior, especially shortly before or after other suspicious activity. Useful sources include Linux auditd execve records, EDR process telemetry, shell history where available, command-line logging, file creation events in temporary directories, and container runtime logs. Look for custom proof-of-concept binaries, repeated execution from /tmp, /var/tmp, /dev/shm, or container writable layers, process names referencing io_uring or waitid, and signs of local reconnaissance or exploit chaining. Kernel logs are unlikely to show a clear error for this issue unless separate security instrumentation is present.

• IORING_OP_WAITID
• io_uring_waitid
• waitid_info
• io_waitid
• io_uring_prep_waitid
• /tmp/io_uring_waitid
• /tmp/waitid_poc
• /var/tmp/io_uring_waitid
• /var/tmp/waitid_poc
• /dev/shm/io_uring_waitid
• /dev/shm/waitid_poc

What your security team should do

• Prioritize patching shared Linux systems, container hosts, CI/CD runners, bastion hosts, research clusters, and other platforms where untrusted local code can run.
• Inventory Linux kernels in use and map them to vendor advisories for this io_uring waitid information disclosure fix.
• Reboot systems after kernel updates and verify the active kernel is the fixed version.
• Where patching is delayed, reduce local attack surface by limiting untrusted user access and restricting workloads that can use io_uring when feasible.
• Monitor for suspicious local exploit research activity involving io_uring, waitid, unusual child-process handling, or repeated probing binaries, especially on multi-tenant systems.
• Treat this primarily as an information-leak primitive that may be combined with other vulnerabilities, rather than as a standalone remote compromise risk.