Cloudanix VulnDB

CVE-2026-80858

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem inside the Linux kernel when handling certain file-system operations could cause crashes or unpredictable system behavior on affected machines.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Insufficient memory ordering when publishing a fuse_ring_queue pointer allows concurrent lockless readers to dereference a partially initialized structure because WRITE_ONCE lacks release semantics.

Why it matters to the business

Linux systems using FUSE with io_uring may experience kernel crashes, undefined behavior, or instability during concurrent queue creation and access, increasing operational risk for storage and file-system workloads.

How an attack unfolds

An attacker triggers fuse_uring_create_queue while other threads concurrently read ring->queues[qid]; the missing release barrier lets readers observe uninitialized fields, resulting in crashes or memory corruption.

How to fix it

Upgrade the Linux kernel to a version containing the fix that replaces WRITE_ONCE with smp_store_release when publishing ring->queues[qid] and ensures READ_ONCE usage in concurrent reader paths.

How to confirm the fix worked

Inspect the fuse_uring_create_queue implementation and reader sites in the kernel source to confirm smp_store_release and READ_ONCE are present; test concurrent queue creation under load after patching.

Typical attack path

  1. Mount a FUSE filesystem configured for io_uring
  2. Trigger queue creation under fch->lock
  3. Concurrently perform lockless reads of the queue pointer from another thread
  4. Dereference uninitialized queue fields due to missing ordering

How to detect it

Search kernel logs and crash dumps for FUSE and io_uring related oops or warnings occurring around queue creation; no public exploitation artifacts are known at this time.

What your security team should do

  • Apply the corrected kernel version as soon as it is available in your distribution
  • Temporarily disable io_uring for FUSE mounts if the workload permits until patches are deployed
  • Review FUSE usage across the fleet and prioritize high-traffic systems

The record

In the Linux kernel, the following vulnerability has been resolved: fuse: publish io-uring queues with release semantics fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the fch->lock. There are several readers that may concurrently be fetching that pointer locklessly and then deferencing it. WRITE_ONCE() doesn't ensure ordering of the queue's field initialization before the ring->queues[qid] pointer assignment. The queue must be published with smp_store_release() so the field initialization is guaranteed to happen before. Readers in paths where the read may happen concurrently with the store need to use READ_ONCE() because any race involving a plain access is undefined.

Affected packages

Ecosystem Package Introduced Fixed