Look up another CVE · open CVE-2026-89836 in the interactive tracker

CVE-2026-89836

f2fs: fix folio_nr_pages() race after put in large folio invalidate

7.8 EPSS 0.2% AV:L

Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem fs/f2fs. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-89836 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	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

Our v6.18 based Android system is continuely suffering livelock and bad page stat as shown in[1] which related to broken xarray slot status. By investigating big folio operations within f2fs, we find below races and fix it by get the nr_pages before drop the refcount and folio_lock. f2fs_get_read_data_folio() calls f2fs_folio_put() before folio_nr_pages() when invalidating a large folio from the page cache. That unlocks the folio and drops the caller reference, leaving a window where a concurrent truncate or folio split can shrink the compound folio or free it before the invalidate range is computed. An undersized range then leaves split sub-folios in mapping->i_pages, which can later interact badly with truncate and reclaim (stale xarray entries and bad page state when folio->mapping no longer matches the mapping being truncated). [1] PID: 2594 TASK: ffffff8169b81580 CPU: 7 COMMAND: "Thread-3" #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798 #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10

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/data.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 f2fs

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, 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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-09-16 (33 days 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.17%, higher than 5.3% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
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
7.0	7.2.5	cc34df18da92
7.0	7.3	0dab71381f1b

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 bug is in f2fs_get_read_data_folio() on a locally mounted f2fs volume, reached when GC or other f2fs helpers grab a single-page folio while a large folio is cached. f2fs is the Android/embedded userdata filesystem; the path is local syscalls, not a network protocol.
AC:LAttack complexity, low: The attacker drives both sides of the race: one thread keeps large folios cached and forces GC via writes into f2fs_balance_fs, while concurrent threads split or reclaim those folios with posix_fadvise(DONTNEED), madvise, or memory pressure in the window after f2fs_folio_put() and before folio_nr_pages().
PR:LPrivileges required, low: CAP_LINUX_IMMUTABLE is needed only to set the flag, but Android f2fs /data already has immutable/fsverity files with large folios. An unprivileged app can read them, write its own data to trigger GC without CAP_SYS_ADMIN, and race reclaim; the GC ioctl is optional.
UI:NUser interaction, none: The attacker can populate large folios, force GC, and race folio split or reclaim with their own processes; no separate victim action is required.
S:UScope, unchanged: Page-cache xarray corruption and folio use-after-free stay inside the host kernel; this is local privilege escalation, not a VM, IOMMU, or sandbox boundary crossing.
C:HConfidentiality impact, high: After the put, folio_nr_pages() may run on a split or already-freed folio, and an undersized invalidate leaves stale i_pages xarray entries. That page-cache UAF allows a reused folio to be read as another mapping's pages, enabling kernel memory disclosure.
I:HIntegrity impact, high: Stale mapping->i_pages slots and UAF of compound-folio metadata are heap and page-cache corruption. Reused folios and later truncate or reclaim against the wrong mapping yield write primitives and control-flow hijacking, not only a crash.
A:HAvailability impact, high: The reported failure is livelock and bad page state in truncate_inode_pages_range (xas_load/find_get_entries) during inode eviction, i.e. a kernel oops, BUG, or hang with complete loss of availability.