cbcvebase.
CVE-2025-68358
published 2025-12-24

CVE-2025-68358: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the…

PriorityP422medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.17%
6.3th percentile
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:

Affected

62 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.164-1 (bookworm)linux 6.1.164-1 (bookworm)
debianlinux-6.1< linux 6.1.164-1 (bookworm)linux 6.1.164-1 (bookworm)
linuxlinux
linuxlinux>= 957780eb2788d8c218d539e19a85653f51a96dc1 < b0bb67385480a3aa4c54b139e4f371ddd06b5150b0bb67385480a3aa4c54b139e4f371ddd06b5150
linuxlinux>= 957780eb2788d8c218d539e19a85653f51a96dc1 < 55835646da78e83e7ad06abd741ca8fd8c0b0ea755835646da78e83e7ad06abd741ca8fd8c0b0ea7
linuxlinux>= 957780eb2788d8c218d539e19a85653f51a96dc1 < d4a81b8ec639895999275ea2472c69825cd67ea4d4a81b8ec639895999275ea2472c69825cd67ea4
linuxlinux>= 957780eb2788d8c218d539e19a85653f51a96dc1 < db4ae18e1b31e0421fb5312e56aefa382bbc6ecedb4ae18e1b31e0421fb5312e56aefa382bbc6ece
linuxlinux>= 957780eb2788d8c218d539e19a85653f51a96dc1 < 6f442808a86eef847ee10afa9e6459494ed85bb36f442808a86eef847ee10afa9e6459494ed85bb3
linuxlinux>= 957780eb2788d8c218d539e19a85653f51a96dc1 < 742b90eaf394f0018352c0e10dc89763b2dd5267742b90eaf394f0018352c0e10dc89763b2dd5267
linuxlinux>= 957780eb2788d8c218d539e19a85653f51a96dc1 < 38e818718c5e04961eea0fa8feff3f100ce4040838e818718c5e04961eea0fa8feff3f100ce40408
linuxlinux_kernel>= 0 < 6.1.164-16.1.164-1
linuxlinux_kernel>= 0 < 6.12.69-16.12.69-1
linuxlinux_kernel>= 0 < 6.17.13-16.17.13-1
linuxlinux_kernel>= 0 < 6.17.0-19.196.17.0-19.19
linuxlinux_kernel>= 4.8 < 5.15.2015.15.201
linuxlinux_kernel>= 5.16 < 6.1.1646.1.164
linuxlinux_kernel>= 6.13 < 6.17.136.17.13
linuxlinux_kernel>= 6.18 < 6.18.26.18.2
linuxlinux_kernel>= 6.2 < 6.6.1246.6.124
linuxlinux_kernel>= 6.7 < 6.12.686.12.68
msrcazl3_kernel_6.6.117.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-3_on_azure_linux_3.0
msrcazl3_kernel_6.6.121.1-1_on_azure_linux_3.0
msrccbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.2HIGH
vendor_ubuntu7.8HIGH
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.