Skip to main content

Linux Kernel EUVDEUVD-2026-35373

| CVE-2026-46315 MEDIUM
2026-06-09 Linux GHSA-3xr6-r26v-fpqm
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

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.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 08, 2026 - 15:52 vuln.today
CVSS changed
Jul 08, 2026 - 14:52 NVD
5.5 (MEDIUM)
Patch available
Jun 09, 2026 - 10:01 EUVD
CVE Published
Jun 09, 2026 - 07:38 nvd
MEDIUM 5.5
CVE Published
Jun 09, 2026 - 07:38 nvd
UNKNOWN (no severity yet)

DescriptionNVD

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.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed

Share

EUVD-2026-35373 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy