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: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The CVE describes a data race in the fuse-uring subsystem of the Linux kernel. On weakly-ordered processors, an out-of-order store to the fiq->ops pointer can occur after the ready flag for a fuse-uring ring is set. A CPU that observes ring->ready as true may then dispatch requests through a stale or invalid fiq->ops pointer, potentially corrupting kernel memory or causing a crash. This flaw constitutes a race condition that can result in loss of availability.

Affected Systems

All Linux kernel releases that do not include the commits that add smp_store_release/smp_load_acquire ordering and READ_ONCE wrappers to the fuse-uring ready flag logic. Kernels predating those commits remain vulnerable.

Risk and Exploitability

The CVE has a CVSS score of 7.8, indicating high severity, while the EPSS score is reported as less than 1%, suggesting a very low exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that exploitation would require an attacker with local capabilities able to trigger fuse-uring operations, as the race occurs during user-initiated fuse-uring requests. No public exploit is currently known.

Generated by OpenCVE AI on August 8, 2026 at 19:50 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that contains the fuse-uring data race fix, which replaces the unsafe store with smp_store_release and the load with smp_load_acquire, and adds READ_ONCE wrappers.
  • If a kernel upgrade cannot be performed immediately, disable fuse-uring support by disabling the generic fuse module or setting CONFIG_FUSE_FUSE2=n and removing it from the kernel configuration.
  • When fuse-uring must remain enabled, restrict its use to trusted or sandboxed environments and avoid running applications that heavily exercise fuse-uring or FUSE devices to reduce the likelihood of triggering the race.

Generated by OpenCVE AI on August 8, 2026 at 19:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 08 Aug 2026 20:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Sat, 08 Aug 2026 18:15:00 +0000

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

Sat, 08 Aug 2026 15:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

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-17T04:58:09.400Z

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

Link: CVE-2026-64588

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-06T08:16:34.123

Modified: 2026-08-17T05:18:05.207

Link: CVE-2026-64588

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-08T20:00:04Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')