Look up another CVE · open CVE-2024-44941 in the interactive tracker
CVE-2024-44941
f2fs: fix to cover read extent cache access with lock
Published 2024-08-26 (2 years ago) by the Linux kernel CNA. Subsystem fs/f2fs. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-44941 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.10.6-1 | Update the kernel and reboot. Fixed in 6.10.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.10.6-1 | Update the kernel and reboot. Fixed in 6.10.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.10.6-1 | Update the kernel and reboot. Fixed in 6.10.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
syzbot reports a f2fs bug as below: BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097 CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 do_read_inode fs/f2fs/inode.c:509 [inline] f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560 f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237 generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413 exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444 exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584 do_handle_to_path fs/fhandle.c:155 [inline] handle_to_path fs/fhandle.c:210 [inline] do_handle_open+0x495/0x650 fs/fhandle.c:226 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We missed to cover sanity_check_extent_cache() w/ extent cache lock, so, below race case may happen, result in use after free issue. - f2fs_iget - do_read_inode - f2fs_init_read_extent_tree : add largest extent entry in to cache - shrink - f2fs_shrink_read_extent_tree - __shrink_extent_tree - __detach_extent_node : drop largest extent entry - sanity_check_extent_cache : access et->largest w/o lock let's refactor sanity_check_extent_cache() to avoid extent cache access and call it before f2fs_init_read_extent_tree() to fix this issue.
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/f2fs/extent_cache.c
fs/f2fs/f2fs.h
fs/f2fs/inode.c
- What this is
- F2FS FILE SYSTEMMAINTAINERS section matched on fs/f2fs/ · linux-f2fs-devel@lists.sourceforge.net · Maintained
- Kernel module
- f2fs
Check it on the machine
grep -w CONFIG_F2FS_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 f2fsPrints 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, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_F2FS_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
Signals
- Published
- 2024-08-26 (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.21%, higher than 10.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/f2fs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.8 | 6.6.47 | 263df78166d3 |
| 3.8 | 6.10.6 | 323ef20b5558 |
| 3.8 | 6.11 | d7409b05a64f |
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 reached through ordinary VFS syscalls (`open`/`stat`/`open_by_handle_at`) that instantiate an f2fs inode via `f2fs_iget()`->`do_read_inode()`, requiring a local account with access to a mounted f2fs filesystem. There is no remote or adjacent-network protocol handler on the path.
- AC:LAttack complexity, low
- The attacker controls both sides of the race: they force the shrinker side by inflating extent-cache memory past the `f2fs_available_free_memory(READ_EXTENT_CACHE)` watermark so `f2fs_balance_fs_bg()`/`f2fs_shrink_scan()` run `f2fs_shrink_read_extent_tree()` continuously, and drive the iget side by repeatedly evicting and re-instantiating inodes. syzbot reproduced it in default configuration (`READ_EXTENT_CACHE` is set by `default_options()`).
- PR:LPrivileges required, low
- No capability, owner, or privilege check exists anywhere on the `f2fs_lookup`/`f2fs_iget`/`do_read_inode`/`sanity_check_extent_cache ` path — any unprivileged user who can look up a file on an f2fs mount reaches it (e.g. any app on Android's f2fs `/data`).
- UI:NUser interaction, none
- The attacker performs the entire sequence with their own file operations and memory pressure against an already-mounted filesystem; no victim action is required.
- S:UScope, unchanged
- The corruption and its consequences are confined to the kernel's own memory and the local system's security authority, with no crossing of a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- This is a slab-use-after-free read of a freed `extent_tree`; the attacker can groom the freed slot with controlled data, and the leaked `largest` extent is then installed as the inode's read-extent mapping, redirecting file reads to arbitrary data blocks and disclosing other files' contents, while the `f2fs_warn` also prints freed heap contents to the log.
- I:HIntegrity impact, high
- Beyond the read, the `CP_ERROR_FLAG` branch writes into the freed object (`ei->len = 0; et->largest_updated = true;`), giving a write primitive into a reallocated slab object, and the poisoned extent mapping causes subsequent I/O to be directed at attacker-influenced block addresses — a UAF of this shape is leverageable for control-flow hijack.
- A:HAvailability impact, high
- The confirmed KASAN slab-use-after-free crashes the kernel, and the garbage `largest.blk` additionally drives `f2fs_is_valid_blkaddr()` failure paths (`f2fs_handle_error`, `SBI_NEED_FSCK`, `dump_stack`) that panic the system under `errors=panic`/`CONFIG_F2FS_CHECK_FS`, and can be retriggered at will.