CVE-2024-44942

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 poisoned inode reaches `gc_data_segment()` only after a local mount of an attacker-supplied f2fs image via loop device or removable media, and the triggering GC/writeback activity is entirely local kernel work. There is no network or adjacent-network path into the f2fs garbage collector.

AC:LAttack complexity, low

Setting `F2FS_INLINE_DATA` in the inode while leaving a valid blkaddr in its direct node is a direct on-disk edit, and `is_alive()` plus the phase-4 checks then pass deterministically; background GC is enabled by default and the attacker can size the image so free sections run low, forcing migration on demand. No race, timing, or memory-layout condition outside the attacker's control is involved.

PR:LPrivileges required, low

An unprivileged local user gets the crafted image mounted through loop devices or desktop/kiosk/Android automounters (udisks2, systemd, vold), and no capability check exists on the GC or writeback path that follows. This matches how the repo scores equivalent f2fs on-disk validation bugs (CVE-2024-47690, CVE-2024-56692).

UI:NUser interaction, none

In the automount/loop scenario the attacker performs the mount itself and the background GC kthread plus the flusher worker drive the crash asynchronously. No separate victim action is required.

S:UScope, unchanged

The BUG_ON panic, the stuck page/node-page locks, and the corrupted inode block-pointer array all remain inside the kernel's own security authority and the mounted filesystem. No VM, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

On the non-`CONFIG_F2FS_CHECK_FS` path the WARN is non-fatal and the inode's `i_addr[]` array is replaced with attacker-chosen 32-bit values that f2fs subsequently dereferences as block addresses in `f2fs_get_dnode_of_data()`/`f2fs_map_blocks()`, allowing in-range blocks belonging to other files on the volume to be read back. The persisted metadata corruption therefore yields cross-file content disclosure, not merely a crash.

I:HIntegrity impact, high

`memcpy_from_page(inline_data_addr(inode, dn.inode_page), page, 0, MAX_INLINE_DATA(inode))` stomps roughly the whole `i_addr[]` block-pointer array of the inode with the contents of an unrelated data block the attacker controls, and `set_page_dirty(dn.inode_page)` writes that back to disk. The result is attacker-controlled corruption of filesystem metadata that the kernel only flags with `SBI_NEED_FSCK` rather than rejecting.

A:HAvailability impact, high

With `CONFIG_F2FS_CHECK_FS` the reported failure is an outright `kernel BUG at fs/f2fs/inline.c:258` inside the writeback kworker, which dies holding the data page lock and the locked inode node page so every subsequent access to that inode and the bdi flusher deadlocks; without it the `WARN_ON` is fatal under `panic_on_warn` and otherwise repeats on every GC pass while marking the filesystem as needing fsck.