CVE-2025-23132

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 path is entered purely through local syscalls against a mounted f2fs volume — `syncfs()`, `fsync()` or `__f2fs_ioctl()` reaching `f2fs_sync_fs` → `f2fs_issue_checkpoint` → `block_operations`. There is no remote or network-facing route into f2fs checkpointing.

AC:HAttack complexity, high

The attacker can spam the checkpoint side at will, but `down_read_trylock(&sb->s_umount)` only fails while a *writer* holds the lock, and every writer (mount/remount/umount/freeze/quotaon-off/shutdown ioctl) is a CAP_SYS_ADMIN operation the unprivileged attacker cannot initiate; the lock must additionally be released or be tearing down quota within the narrow window before `dquot_writeback_dquots()`. That timing dependency on an administrative mount-state change is beyond the attacker's control.

PR:LPrivileges required, low

The attacker-facing half needs no privilege at all — any local user with a file or fd on the f2fs mount can loop on `syncfs()`/`fsync()` to drive checkpoints, which is the case on every Android device where `/data` is f2fs with the `quota_ino` feature enabled by default. No capability, and no user namespace, is required on the triggering path.

UI:NUser interaction, none

The attacker issues the triggering syscall themselves and nothing must be opened, mounted or clicked on their behalf. The concurrent administrative remount is a timing precondition already accounted for in Attack Complexity, not victim participation in the attack.

S:UScope, unchanged

The damage is confined to kernel memory and kernel-managed quota/filesystem state within the same security authority. No hypervisor, IOMMU or sandbox boundary is crossed.

C:HConfidentiality impact, high

Running `dquot_writeback_dquots()`/`f2fs_quota_sync_file()` without `s_umount` removes exactly the protection that keeps quota state alive — `dqopt->files[type]->i_mapping` is dereferenced after only a lockless `sb_has_quota_active()` check, and `dqopt->info[cnt].dqi_dirty_list` is walked while `invalidate_dquots()` frees its entries. A use-after-free read of `struct inode`/`struct dquot` in a general-purpose slab is leverageable for disclosure of adjacent kernel objects.

I:HIntegrity impact, high

The same unsynchronized window lets `filemap_fdatawrite()` and `dquot_write_dquot()` write through a quota inode that `vfs_cleanup_quota_inode()` has already `iput()`ed and NULLed, giving a write into freed slab memory alongside corruption of on-disk quota accounting (f2fs flags `SBI_QUOTA_NEED_REPAIR`, requiring fsck). A use-after-free write is a classic route to control-flow hijack.

A:HAvailability impact, high

The immediate, reported effect is a `WARNING` splat that taints the kernel and is an outright panic on the many hardened Android, cloud and embedded builds that set `panic_on_warn=1`. Beyond that, the lost lock readily oopses the kernel via NULL dereference of a cleared `dqopt->files[type]` or a use-after-free on the quota inode.