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

CVE-2024-26944

btrfs: zoned: fix use-after-free in do_zone_finish()

7.8 EPSS 0.2% AV:L

Published 2024-05-01 (2 years 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-26944 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.8.9-1	Update the kernel and reboot. Fixed in 6.8.9-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	6.8.9-1	Update the kernel and reboot. Fixed in 6.8.9-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	6.8.9-1	Update the kernel and reboot. Fixed in 6.8.9-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0xb3/0x4e0 [btrfs] device_list_add.constprop.0+0x993/0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs] btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400) The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb This UAF happens because we're accessing stale zone information of a already removed btrfs_device in do_zone_finish(). The sequence of events is as follows: btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- device freed cleaner_kthread btrfs_delete_unused_bgs btrfs_zone_finish do_zone_finish <-- refers the freed device The reason for this is that we're using a ---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/zoned.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 -wE 'CONFIG_BLK_DEV_ZONED|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 switches: CONFIG_BLK_DEV_ZONED, CONFIG_BTRFS_FS
Reads as: all on means the file is compiled; any one off means it is not.

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: 2024-05-01 (2 years 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.24%, higher than 14.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
5.18	6.8.3	34ca809e055e
5.18	6.9	1ec17ef59168

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 vulnerability is reached through ordinary local filesystem activity (writes, deletions, ordered-extent completion, unused-block-group cleanup) on a mounted zoned btrfs; there is no network-facing component.
AC:LAttack complexity, low: Once a device replace has completed, `block_group->physical_map` holds a permanently dangling `btrfs_device` pointer, so triggering `do_zone_finish()` via ordinary file I/O is deterministic and requires winning no race; the reporter reproduced it with a stock fstests run (btrfs/070).
PR:LPrivileges required, low: The attacker needs only write access to the mounted zoned btrfs to drive `btrfs_zone_finish_endio()`/`btrfs_delete_unused_bgs()` into the freed device, and can additionally groom the kmalloc-1k slab from unprivileged context; the CAP_SYS_ADMIN device replace that creates the dangling pointer is routine admin maintenance (the primary use case for zoned btrfs on SMR drives), not a privilege the attacker must hold.
UI:NUser interaction, none: After the stale pointer exists, the btrfs cleaner kthread and normal write-completion paths call `do_zone_finish()` automatically, and the attacker can force them with their own file operations without any victim action.
S:UScope, unchanged: The corruption is confined to kernel slab memory within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.
C:HConfidentiality impact, high: The freed 1KB `btrfs_device` and `btrfs_zoned_device_info` objects are read after free, and slab grooming lets the attacker control the reallocated contents, turning `device->zone_info`/`device->bdev` dereferences into an attacker-directed kernel read primitive.
I:HIntegrity impact, high: `do_zone_finish()` performs UAF writes — `zinfo->reserved_active_zones++`, `atomic_inc(&zone_info->active_zones_left)`, and `test_and_clear_bit(zno, zone_info->active_zones)` with pointer and index both taken from freed memory — giving a controllable write/bit-clear primitive usable for control-flow hijacking, plus zone-management commands issued through a dangling `bdev`.
A:HAvailability impact, high: The bug is a KASAN-confirmed slab use-after-free in the btrfs cleaner kthread that reliably oopses or panics the kernel, and it also drives blkdev_zone_mgmt() with freed block-device state.