Description
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.
Published: 2026-08-06
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel contains a data race in the fuse‑uring ready flag that can cause a CPU to observe the flag as set while still using a stale or invalid FIQ operation pointer. On weakly‑ordered architectures the store to the operations pointer may be reordered after the ready flag store, allowing an attacker to dispatch requests through a stale pointer, potentially corrupting kernel state or causing a crash. The vulnerability also hides a marked‑vs‑unmarked access that the kernel safety checker will flag. The fix upgrades the store to smp_store_release and the load to smp_load_acquire, and wraps the ready flag checks with READ_ONCE to guarantee visibility and prevent stale dereferences.

Affected Systems

All Linux kernels implementing fuse‑uring that do not yet contain the commits that introduce the smp_store_release/smp_load_acquire and READ_ONCE wrappers are vulnerable. The description does not enumerate specific kernel versions, but any build prior to the commits referenced (46725a0056c884cf58a6897f222892807327d82d, b156bb9966972122b148acab8bdf415cdb8176a3, d01a09b442cb786cd44ccc7c84d57e2856d6737c) is vulnerable. The flaw is not listed in CISA’s KEV catalog and the EPSS score is unavailable.

Risk and Exploitability

This is a kernel‑level concurrency bug that can lead to denial of service or kernel memory corruption. The CVSS score is not provided, but the nature of the flaw suggests high severity. Exploitation requires local access that can trigger fuse‑uring operations; no public exploit has been reported and the EPSS score is unavailable, so the likelihood is uncertain. Nonetheless, operators should treat the vulnerability as an elevated local risk until the patch is applied.

Generated by OpenCVE AI on August 6, 2026 at 08:53 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the kernel to a version that includes the fuse‑uring data race fix (see commit 46725a0056c884cf58a6897f222892807327d82d).
  • If an immediate kernel update is not possible, disable fuse‑uring support or prevent its use in user space to eliminate the vulnerable code path.
  • After applying the patch, reboot the system or reload the kernel to ensure the new code is active and verify that the kernel image matches the patched build.

Generated by OpenCVE AI on August 6, 2026 at 08:53 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 06 Aug 2026 09:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665
CWE-730

Thu, 06 Aug 2026 07:30:00 +0000

Type Values Removed Values Added
Description 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.
Title fuse-uring: fix data races on ring->ready
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-06T07:13:46.688Z

Reserved: 2026-07-19T15:36:31.798Z

Link: CVE-2026-64588

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-06T09:15:02Z

Weaknesses