Skip to main content

Linux Kernel CVE-2026-64425

| EUVDEUVD-2026-48769 MEDIUM
2026-07-25 Linux GHSA-rmw8-w7cg-rwfm
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

Local low-privilege DoS via race in io_uring worker; no confidentiality or integrity impact, availability-only hang.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
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

6
Metadata Corrected
Sep 04, 2026 - 16:40 vuln.today
tag: Information Disclosure removed
Analysis Generated
Sep 04, 2026 - 16:13 vuln.today
CVSS changed
Sep 04, 2026 - 15:52 NVD
5.5 (MEDIUM)
Patch available
Jul 25, 2026 - 11:18 EUVD
CVE Published
Jul 25, 2026 - 08:51 nvd
MEDIUM 5.5
CVE Published
Jul 25, 2026 - 08:51 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item

commit 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.

io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun.

Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.

AnalysisAI

Availability impact in the Linux kernel's io_uring work queue (io-wq) subsystem allows a local, low-privileged user to cause an extended hang during io_uring ring closure. The root cause is a race condition in io_worker_handle_work(): the IO_WQ_BIT_EXIT check is snapshotted once before processing a linked-work chain, so if io_wq_exit_start() fires mid-chain, remaining linked items execute with a stale do_kill=false, skip IO_WQ_WORK_CANCEL, and continue running after exit has been initiated. No public exploit is identified at time of analysis; the issue was surfaced by syzbot using slow MSR-device reads with linked work chains and immediate ring close.

Technical ContextAI

The io_uring subsystem in the Linux kernel uses an internal work queue (io-wq) to dispatch asynchronous work items, including chains of linked dependent tasks. The worker thread function io_worker_handle_work() iterates over work items; a prior fix (commit 10dc95939817) added an IO_WQ_BIT_EXIT re-check in the outer work run loop but left a residual race: the exit bit is still read once per linked-work chain rather than per item. When io_wq_exit_start() sets IO_WQ_BIT_EXIT between items in a chain, subsequent items see the stale snapshot, bypass the cancellation path (IO_WQ_WORK_CANCEL), and continue executing. The fix moves the exit-bit check inside the linked-item loop so every item is individually gated. CWE is not assigned, but the class is a TOCTOU/check-time-use-time race condition (CWE-367) on a shared flag. Affected CPE: cpe:2.3:a:linux:linux across multiple stable branches.

RemediationAI

Upgrade to a patched Linux kernel version: 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.96, 6.18.39, 7.1.4, or 7.2-rc1 as appropriate for the running kernel series. Fix commits are indexed at git.kernel.org/stable and available via the kernel's stable-updates tree. For distributions that have not yet shipped the patch, a compensating control is to restrict io_uring access to trusted processes via the kernel's io_uring_disabled sysctl (set /proc/sys/kernel/io_uring_disabled=1 to disable io_uring system-wide, or =2 to limit it to processes with CAP_SYS_ADMIN); this eliminates the attack surface entirely but breaks applications that depend on io_uring (notably newer versions of liburing-based servers). Alternatively, seccomp profiles or Landlock policies can be used to block the io_uring syscall for untrusted processes without system-wide impact.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected

Share

CVE-2026-64425 vulnerability details – vuln.today

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