CVE-2025-38333

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

get_new_segment() is reached only through the f2fs allocator on a locally mounted volume — ordinary writes, fsync, GC, or the background checkpoint thread; there is no network-facing consumer of this code.

AC:LAttack complexity, low

Once the free_segmap/free_secmap divergence exists — from attacker-supplied on-disk metadata on removable f2fs media or the in-kernel state divergence observed in the field — the condition is hit deterministically on the next allocation from that section, with no race window or memory layout the attacker must win.

PR:LPrivileges required, low

On an already-mounted f2fs volume (Android /data, auto-mounted SD/USB), any unprivileged local user with write access drives segment allocation via normal file writes and fsync; no capability or CAP_SYS_ADMIN is needed for the trigger itself.

UI:NUser interaction, none

The reported failure fires on the background checkpoint kthread during ordinary operation on an already-mounted filesystem, and removable f2fs media are auto-mounted by vold/udisks2 without any action by another user.

S:UScope, unchanged

The corruption is confined to the kernel/f2fs security authority on the same host; no VM, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

The already-in-use segment is handed out as a new current segment starting at block offset 0, so the same physical blocks become mapped by two different inodes and a reader of one file obtains blocks written for another user's file on a shared filesystem.

I:HIntegrity impact, high

Live data and node blocks belonging to other files are physically overwritten, SIT valid_blocks/cur_valid_map are corrupted, and the underflowed free_segments count is persisted into the on-disk checkpoint (ckpt->free_segment_count is never validated on read), so the damage survives reboot.

A:HAvailability impact, high

With CONFIG_F2FS_CHECK_FS the f2fs_bug_on is a plain BUG_ON taken while holding free_i->segmap_lock on the checkpoint kthread — an immediate panic; otherwise the free_segments/free_sections underflow defeats GC accounting and the downstream f2fs_bug_on()s and -ENOSPC path end in f2fs_stop_checkpoint(), shutting the filesystem down.