Look up another CVE · open CVE-2026-89829 in the interactive tracker
CVE-2026-89829
f2fs: fix to pass folio->index to f2fs_sanity_check_node_footer()
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-89829 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
Otherwise in f2fs_sanity_check_node_footer(), it will check the same nid incorrectly.
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/node.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
- 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 6.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 |
|---|---|---|
| 6.18.13 | 6.18.51 | a984446aa9d5 |
| 7.0 | 7.2.5 | 0b196c07407f |
| 7.0 | 7.3 | 7e188e9f9437 |
| 6.19.3 | 0 | 0 |
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 defect is in f2fs __write_node_folio() on the node-mapping writeback path, reached only from local VFS operations (fsync, write, checkpoint, GC, or reclaim) on a mounted f2fs volume; no network protocol (ksmbd/nfsd/packet) processes this node-footer check.
- AC:LAttack complexity, low
- A crafted f2fs image fully controls the on-disk node footer nid. Related syzbot reports show that async node readahead of a fuzzed image followed by writeback deterministically hits the mismatched-nid case, with no race or layout the attacker cannot arrange.
- PR:LPrivileges required, low
- Mounting f2fs requires privilege (no FS_USERNS_MOUNT), but once the volume is mounted—Android userdata, automounted SD/USB, or a shared workstation—any unprivileged local user can dirty node pages via write/fsync/fallocate/truncate and enter __write_node_folio with no capability check.
- UI:NUser interaction, none
- After the crafted image is mounted, the attacker triggers node writeback themselves through ordinary file syscalls or in-kernel checkpoint/reclaim; no separate victim action such as opening a file or confirming a prompt is required.
- S:UScope, unchanged
- The impact is kernel memory and f2fs metadata corruption on the host that mounted the volume; it does not cross a VM, IOMMU, or guest-to-host security boundary.
- C:HConfidentiality impact, high
- __write_node_folio uses the attacker-controlled footer nid as the NAT key without a range check, so current_nat_addr() indexes nat_bitmap at an attacker-chosen offset (nid/NAT_ENTRY_PER_BLOCK), an unbounded out-of-bounds kernel read. The same nid confusion later parses the planted node with the wrong layout, leaking adjacent folio contents as in CVE-2025-40025.
- I:HIntegrity impact, high
- set_node_addr() and f2fs_do_write_node_page() commit the node folio under the footer nid, overwriting an arbitrary NAT entry and remapping any node. Subsequent operations on that nid write through the wrong inode-vs-dnode layout, producing out-of-bounds metadata writes past the node folio.
- A:HAvailability impact, high
- A mismatched nid that fails f2fs_get_node_info() takes redirty_out, looping writepages indefinitely (the hang this check was added to stop). A nid that proceeds hits f2fs_bug_on() in set_node_addr()/write_end_io, panicking with CONFIG_F2FS_CHECK_FS or WARNing and corrupting the filesystem otherwise.