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

CVE-2024-57975

btrfs: do proper folio cleanup when run_delalloc_nocow() 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-57975 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.13-1	Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	6.12.13-1	Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	6.12.13-1	Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

[BUG] With CONFIG_DEBUG_VM set, test case generic/476 has some chance to crash with the following VM_BUG_ON_FOLIO(): BTRFS error (device dm-3): cow_file_range failed, start 1146880 end 1253375 len 106496 ret -28 BTRFS error (device dm-3): run_delalloc_nocow failed, start 1146880 end 1253375 len 106496 ret -28 page: refcount:4 mapcount:0 mapping:00000000592787cc index:0x12 pfn:0x10664 aops:btrfs_aops [btrfs] ino:101 dentry name(?):"f1774" flags: 0x2fffff80004028(uptodate|lru|private|node=0|zone=2|lastcpupid=0xfffff) page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio)) ------------[ cut here ]------------ kernel BUG at mm/page-writeback.c:2992! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 2 UID: 0 PID: 3943513 Comm: kworker/u24:15 Tainted: G OE 6.12.0-rc7-custom+ #87 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : folio_clear_dirty_for_io+0x128/0x258 lr : folio_clear_dirty_for_io+0x128/0x258 Call trace: folio_clear_dirty_for_io+0x128/0x258 btrfs_folio_clamp_clear_dirty+0x80/0xd0 [btrfs] __process_folios_contig+0x154/0x268 [btrfs] extent_clear_unlock_delalloc+0x5c/0x80 [btrfs] run_delalloc_nocow+0x5f8/0x760 [btrfs] btrfs_run_delalloc_range+0xa8/0x220 [btrfs] writepage_delalloc+0x230/0x4c8 [btrfs] extent_writepage+0xb8/0x358 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x178/0x3a8 [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: 910a8021 a90363f7 a9046bf9 94012379 (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] The first two lines of extra debug messages show the problem is caused by the error handling of run_delalloc_nocow(). E.g. we have the following dirtied range (4K blocksize 4K page size): 0 16K 32K |//////////////////////////////////////| | Pre-allocated | And the range [0, 16K) has a preallocated extent. - Enter run_delalloc_nocow() for range [0, 16K) Which found range [0, 16K) is preallocated, can do the proper NOCOW write. - Enter fallback_to_fow() for range [16K, 32K) Since the range [16K, 32K) is not backed by preallocated extent, we have to go COW. - cow_file_range() failed for range [16K, 32K) So cow_file_range() will do the clean up by clearing folio dirty, unlock the folios. Now the folios in range [16K, 32K) is unlocked. - Enter extent_clear_unlock_delalloc() from run_delalloc_nocow() Which is called with PAGE_START_WRITEBACK to start page writeback. But folios can only be marked writeback when it's properly locked, thus this triggered the VM_BUG_ON_FOLIO(). Furthermore there is another hidden but common bug that run_delalloc_nocow() is not clearing the folio dirty flags in its error handling path. This is the common bug shared between run_delalloc_nocow() and cow_file_range(). [FIX] - Clear folio dirty for range [@start, @cur_offset) Introduce a helper, cleanup_dirty_folios(), which will find and lock the folio in the range, clear the dirty flag and start/end the writeback, with the extra handling for the @locked_folio. - Introduce a helper to clear folio dirty, start and end writeback - Introduce a helper to record the last failed COW range end This is to trace which range we should skip, to avoid double unlocking. - Skip the failed COW range for the e ---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
fs/btrfs/subpage.h

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.21%, higher than 11.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
3.5	6.12.13	5ae72abbf91e
3.5	6.13.2	2434533f1c96
3.5	6.14	c2b47df81c8e

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: Triggering requires writing to a file on a locally mounted btrfs filesystem (fallocate/chattr +C plus buffered writes and an induced ENOSPC), reached through ordinary VFS syscalls. No network protocol handler parses attacker data on this path.
AC:LAttack complexity, low: The attacker fully controls both preconditions — the extent layout (fallocate a prealloc extent, then dirty a range extending past it) and the allocation failure (fill the filesystem or hit a qgroup limit) — so the error path can be driven deterministically and repeatedly.
PR:LPrivileges required, low: Any unprivileged local user with write access to a btrfs filesystem (home directory, /var/tmp, container storage) can set NODATACOW/PREALLOC on their own files and consume space; no capabilities or root are needed.
UI:NUser interaction, none: The attacker performs all steps itself; writeback is kicked off by the kernel (kworker, memory pressure, or the attacker's own fsync/sync) with no action from any other user.
S:UScope, unchanged: The corruption is confined to kernel page-cache and btrfs writeback state within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.
C:HConfidentiality impact, high: Stray unlock of an already-unlocked folio steals/forges the page lock and the duplicated folio_end_writeback can clear another I/O's writeback bit, allowing a folio with in-flight I/O to be reclaimed and reused, so page-cache contents can be read into or leaked out of the wrong file.
I:HIntegrity impact, high: The double cleanup corrupts folio lock, dirty and writeback state plus delalloc/qgroup accounting, breaking page-cache exclusion so two threads believe they exclusively own the folio; stale dirty folios with no ordered extent can also be written out incorrectly, giving memory/data corruption primitives.
A:HAvailability impact, high: With CONFIG_DEBUG_VM it is an immediate kernel BUG (VM_BUG_ON_FOLIO in folio_clear_dirty_for_io) in a workqueue, and even without it folio_unlock's XOR permanently sets PG_locked on the folio, hanging every subsequent access, writeback, sync and unmount in unkillable D-state.