Skip to main content

Linux Kernel EUVDEUVD-2026-53775

| CVE-2026-64588 HIGH
2026-08-06 Linux GHSA-ww4g-j47r-8q39
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

AC:H replaces NVD's AC:L because triggering the race requires precise timing on a weakly-ordered architecture with fuse-uring active; kernel memory impacts justify C:H/I:H/A:H.

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

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

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

Lifecycle Timeline

5
Analysis Generated
Aug 08, 2026 - 15:38 vuln.today
CVSS changed
Aug 08, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Aug 06, 2026 - 08:16 EUVD
CVE Published
Aug 06, 2026 - 07:13 cve.org
HIGH 7.8
CVE Published
Aug 06, 2026 - 07:13 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

fuse-uring: fix data races on ring->ready

On weakly-ordered architectures, the store to fiq->ops can be reordered past the store to ring->ready, allowing a CPU that sees ring->ready true via fuse_uring_ready() to dispatch requests through a stale fiq->ops pointer. Upgrade the store to smp_store_release() and the load in fuse_uring_ready() to smp_load_acquire() so that the preceding WRITE_ONCE(fiq->ops, ...) is visible to any CPU that observes ring->ready true.

Additionally, fuse_uring_do_register() publishes ring->ready with WRITE_ONCE() but the fast-path check reads it with a plain load. This is a marked-vs-unmarked access that KCSAN will flag. Wrap it in READ_ONCE() to mark it without adding unnecessary ordering.

Also wrap the fc->ring load in fuse_uring_ready() in READ_ONCE() to prevent the compiler from reloading it between the NULL check and the dereference.

AnalysisAI

Memory ordering data races in the Linux kernel's fuse-uring subsystem expose weakly-ordered architecture systems (ARM64, PowerPC, RISC-V) to kernel-level impacts when the fuse-uring ring initializes. On kernels from commit c2c9af9a through the fix, missing acquire/release semantics around ring->ready and fiq->ops allow a CPU to observe ring->ready == true while reading a stale fiq->ops function pointer table, which could trigger undefined behavior ranging from kernel crashes to potential control-flow hijacking. No public exploit has been identified and EPSS sits at 0.15% (5th percentile), indicating low near-term exploitation probability despite the High CVSS rating; no CISA KEV listing confirms active exploitation.

Technical ContextAI

The fuse-uring subsystem provides an io_uring-backed interface for FUSE (Filesystem in Userspace) in the Linux kernel, allowing userspace filesystem operations to be served through the high-performance io_uring ring buffer model. The subsystem uses a ring->ready flag to signal that fiq->ops - the FUSE I/O queue operations function pointer table - is safe to use for dispatching requests. On weakly-ordered CPU architectures such as ARM64, PowerPC, and RISC-V, the absence of proper memory barriers permits the compiler or CPU to reorder stores: ring->ready can become visible to other CPUs before fiq->ops is fully propagated, creating a window where fuse_uring_ready() returns true but a subsequent dispatch dereferences a stale or uninitialized fiq->ops pointer. A secondary issue was a KCSAN-flagged marked-vs-unmarked access where WRITE_ONCE(ring->ready) was paired with a plain load on the fast path. The fix introduces smp_store_release()/smp_load_acquire() pairs and READ_ONCE() wrappers. No CWE is formally assigned, but this maps to CWE-362 (Race Condition / Concurrent Access to Shared Resource Without Proper Synchronization) and CWE-1088 (Synchronization Primitive Not Used or Incorrectly Used). Affected CPE: cpe:2.3:a:linux:linux:*.

RemediationAI

The definitive fix is upgrading to a patched kernel: Linux 6.18.39 or 7.1.4 (or 7.2-rc1 and later), incorporating fix commits b156bb99, d01a09b4, and 46725a00 from git.kernel.org. If immediate kernel upgrade is not feasible, io_uring can be disabled system-wide via 'sysctl -w kernel.io_uring_disabled=2' (available since kernel 5.13), which prevents fuse-uring from executing entirely; the trade-off is that all io_uring-dependent applications will fail, potentially impacting database and storage workloads. A less disruptive option is 'sysctl -w kernel.io_uring_disabled=1', which restricts io_uring to privileged processes only, reducing the attack surface to root-equivalent accounts at the cost of breaking unprivileged io_uring usage. On x86/x86-64 deployments, the runtime risk from the race is minimal due to TSO memory ordering, but patching remains the authoritative fix for cross-architecture correctness. Distribution maintainers should be monitored for backported stable-kernel packages.

Vendor StatusVendor

SUSE

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

Share

EUVD-2026-53775 vulnerability details – vuln.today

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