Cloudanix VulnDB

CVE-2024-57976

High · 7.8

CVSS

7.8

EPSS

0.3%

Published

Feb 27, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how certain filesystems clean up after running out of disk space during writes can make the whole computer crash.

Exploitation
Other
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Improper folio and extent cleanup in btrfs cow_file_range() error path (e.g. -ENOSPC) leaves pages dirty without EXTENT_DELALLOC flags, triggering BUG_ON() in extent_writepage_io COW fixup on subsequent writeback.

Why it matters to the business

Kernel crashes on btrfs volumes during delalloc under space pressure can cause unplanned downtime and potential loss of in-flight writes; low urgency given no KEV listing, low EPSS, and modest prevalence.

How an attack unfolds

An attacker or workload triggers delalloc writeback with insufficient space reservation so cow_file_range fails, error cleanup leaves inconsistent dirty state, and later writeback hits the BUG_ON; no named threat actors observed.

How to fix it

Upgrade copyparty to version 1.8.7; apply the upstream btrfs patch that keeps extents and folios locked until the entire delalloc range succeeds or errors cleanly.

How to confirm the fix worked

Confirm btrfs module contains the folio-locking change in extent_io.c; run delalloc stress tests under ENOSPC conditions and verify absence of the BUG_ON at fs/btrfs/extent_io.c:1444.

Typical attack path

  1. Initiate delalloc write on btrfs inode
  2. Force btrfs_reserve_extent to return -ENOSPC after partial reservation
  3. Execute buggy error cleanup that clears flags but leaves dirty pages
  4. Re-trigger writeback to enter extent_writepage_io without ordered flag

How to detect it

Search kernel logs for 'failed to run delalloc range' followed by BUG at extent_io.c and stack traces containing btrfs_async_reclaim_data_space; inspect kworker traces for extent_writepage_io.

What your security team should do

  • Apply copyparty 1.8.7 update across all instances within standard change windows
  • Monitor EPSS trend and re-evaluate if score rises above 0.01
  • Add btrfs writeback error paths to kernel crash-dump review process

The record

In the Linux kernel, the following vulnerability has been resolved: btrfs: do proper folio cleanup when cow_file_range() failed [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---

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 linux 0 No fix
Debian:12 linux 0 No fix
Debian:13 linux 0 No fix
Linux Kernel 0 6.12.36
Linux Kernel 2.6.32 6.12.36

Related vulnerabilities