CVE-2025-68358

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Dec 24, 2025

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing bug in the Linux storage layer can make the system stop responding to file writes when multiple operations overlap on certain disk setups.

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: Moderate
Impact: Denial Of Service
Component: OS kernel
Class: Race Condition
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

A race condition in btrfs_clear_space_info_full() performs unlocked writes to bitfields (full, chunk_alloc, flush) in struct btrfs_space_info, allowing concurrent RMW operations from other paths such as do_async_reclaim_data_space to corrupt adjacent flags and violate the invariant that flush==0 only when no reclaim work is queued.

Why it matters to the business

Btrfs filesystems on affected kernels can experience indefinite blocking of allocation requests under concurrent transaction commit and reclaim workloads, resulting in application hangs, reduced availability, and operational disruption; low urgency given absent KEV listing, stable low EPSS, and 306 days since publication with no observed exploitation.

How an attack unfolds

An attacker with local execution triggers parallel btrfs_commit_transaction paths that clear the full bit without the space_info lock while a reclaim worker simultaneously clears the flush bit, leaving flush erroneously set and causing subsequent __reserve_bytes callers to enqueue tickets that can never be serviced.

How to fix it

Upgrade to a kernel containing commit b0bb67385480a3aa4c54b139e4f371ddd06b5150 or later stable equivalents; for listed Chainguard images apply ingress-nginx-controller-fips-1.11, kube-webhook-certgen-fips-1.11, and ingress-nginx-custom-error-pages-fips-1.11 at version 1.11.5-r0 or newer; rebuild and redeploy all affected container images and hosts.

How to confirm the fix worked

Confirm the three bitfield members have been replaced by separate bools in btrfs_space_info and that every write path acquires the protecting lock; verify the running kernel contains the referenced commit or package version and run targeted stress tests exercising btrfs_commit_transaction plus reclaim concurrently.

Typical attack path

Obtain local unprivileged code execution on a system running an affected Btrfs kernel
Perform filesystem activity that drives concurrent transaction commits and data-space reclaim
Trigger the unlocked bitfield write in btrfs_clear_space_info_full while the reclaim path holds the lock
Observe allocation requests blocking forever on unserviced tickets

How to detect it

Search kernel logs and task dumps for processes stuck in D-state inside Btrfs allocation or ticket-wait paths; inspect space_info structures via debugfs or crash dumps for flush flag remaining set with empty ticket lists; correlate with concurrent commit and reclaim activity.

What your security team should do

Apply the referenced kernel commit or package updates to all Btrfs hosts within standard change windows
Include the fix in next scheduled kernel and container image rebuild pipelines
Add Btrfs allocation-hang detection to existing filesystem monitoring
Document the change and re-test high-concurrency workloads before broad rollout

The record

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---

Affected packages

Ecosystem	Package	Introduced	Fixed
Linux	Kernel	4.8.0	5.15.201
Linux	Kernel	4.8.0	6.17.13
openSUSE:Tumbleweed	kernel-source	0	6.18.5-1.1
openSUSE:Tumbleweed	kernel-source-longterm	0	6.18.16-1.1