Look up another CVE · open CVE-2024-57976 in the interactive tracker

CVE-2024-57976

btrfs: do proper folio cleanup when cow_file_range() failed

7.8 EPSS 0.2% AV:L

Published 2025-02-27 (20 months ago) by the Linux kernel CNA. Subsystem fs/btrfs. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2024-57976 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	vulnerable	6.1.190-1	No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixie	fixed	6.12.37-1	Update the kernel and reboot. Fixed in 6.12.37-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	6.12.37-1	Update the kernel and reboot. Fixed in 6.12.37-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	6.12.37-1	Update the kernel and reboot. Fixed in 6.12.37-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

[BUG] When testing with COW fixup marked as BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path. This BUG_ON() happens just after a failed btrfs_run_delalloc_range(): BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC. Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling. For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size: 0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################| Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag. - Enter extent_writepage() for page 0 - Enter btrfs_run_delalloc_range() for range [0, 64K) - Enter cow_file_range() for range [0, 64K) - Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K) 0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################| And range [0, 16K) has its delalloc flag cleared. But since we haven't yet submit any bio, involved 4 pages are still dirty. - Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges: 0 16K 32K 48K 64K |////////| | | | | Note that range [0, 16K) still has its pages dirty. - Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags. - btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag. - extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON(). Unfortunately this error handling bug dates back to the introduction of btrfs. Thankfully with the abuse of COW fixup, at least it won't crash the kernel. [FIX] Instead of immediately unlocking the extent and folios, we keep the extent and folios locked until either erroring out or the whole delalloc range finished. When the whole delalloc range finished without error, we just unlock the whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked cases) ---truncated---

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

fs/btrfs/inode.c

What this is: BTRFS FILE SYSTEMMAINTAINERS section matched on fs/btrfs/ · linux-btrfs@vger.kernel.org · Maintained
Kernel module: btrfs

Check it on the machine

grep -w CONFIG_BTRFS_FS /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w btrfs

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

bookworm, trixie, forky, sidm

m: a loadable module on every flavour - check lsmod, can be blacklisted

Build switch: CONFIG_BTRFS_FS

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2025-02-27 (20 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.22%, higher than 12.1% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: fs/btrfs

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.32	6.12.36	10b3772292bf
2.6.32	6.13.2	692cf71173bb
2.6.32	6.14	06f364284794

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The vulnerable code is btrfs's buffered-write delalloc/writeback path, reached by dirtying pages on a locally mounted btrfs filesystem and letting writeback run. No network-facing protocol handler is involved, so local access to a writable btrfs mount is required.
AC:LAttack complexity, low: The attacker fully controls both preconditions — dirtying a range large enough that cow_file_range() iterates over multiple extent reservations, and driving the filesystem into the partial-allocation failure state (ENOSPC via fill/fragmentation, or ENOMEM in btrfs_create_io_em()/btrfs_alloc_ordered_extent()). Nothing depends on state outside the attacker's influence.
PR:LPrivileges required, low: Only an ordinary unprivileged local account with write access to any btrfs filesystem is needed; btrfs is the default root filesystem on several major distributions, and no capability, mount privilege, or admin operation is required.
UI:NUser interaction, none: Writeback is initiated by the kernel itself (background flusher threads and the btrfs_async_reclaim_data_space/shrink_delalloc reclaim worker) or by the attacker's own fsync/sync. No action by any other user is required.
S:UScope, unchanged: The corrupted state and its consequences are entirely within the kernel's own security authority — no VM, container-image, or IOMMU boundary is crossed.
C:HConfidentiality impact, high: The bug leaves folios dirty outside the filesystem's reservation and checksum-tracking machinery with the backing ordered extent and extent map already torn down, so page content can be written back through a path btrfs itself declares "not data checksum safe" and previously-mapped disk blocks can be exposed; the resulting BUG()/oops additionally dumps kernel register and stack state.
I:HIntegrity impact, high: Persistent file data and filesystem accounting are corrupted — dirty pages survive with no delalloc bit, no space reservation and no ordered extent, so subsequent writeback either commits data outside the ordered-extent/checksum machinery or silently discards it via folio_clear_dirty_for_io(), leaving on-disk content inconsistent with what the filesystem tracks.
A:HAvailability impact, high: The commit documents a kernel BUG at fs/btrfs/extent_io.c:1444 (oops in a kworker) taken while the folio and extent range are locked, which permanently wedges every subsequent access to that inode and panics the box under panic_on_oops. Even where the COW-fixup fallback masks the oops, the never-cleaned dirty folios are redirtied and requeued indefinitely, spinning the delalloc-shrink reclaim worker in a livelock.