Cloudanix VulnDB

CVE-2026-63812

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's flash filesystem code can let local programs cause internal tracking errors that may crash the system or damage file data.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in f2fs __destroy_extent_node allows stale largest extent cache (length not reset to zero, inode folio not updated) after FI_NO_EXTENT is set, violating extent tree invariants.

Why it matters to the business

Local users can trigger filesystem sanity check failures, potential extent cache corruption, and crashes or data integrity issues on f2fs volumes, increasing operational risk for systems using this filesystem.

How an attack unfolds

An attacker with local access triggers concurrent f2fs_drop_inode and writeback paths that race on extent node destruction, leaving a non-zero largest extent length that later fails sanity checks or allows invalid extent operations.

How to fix it

Update to a Linux kernel containing the fix that reverts ed78aeebef05 and correctly resets the largest extent length when setting FI_NO_EXTENT; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the commit reverting ed78aeebef05 is present, run xfstests generic/388 on f2fs, and verify no sanity_check_extent_cache errors occur under concurrent drop_inode and writeback workloads.

Typical attack path

  1. Obtain local user access on a system using f2fs
  2. Create or open files to populate the extent cache
  3. Trigger inode eviction via f2fs_drop_inode while writeback is active
  4. Force the stale extent condition to surface via filesystem operations or unmount
  5. Observe or exploit resulting sanity_check_extent_cache failure or cache misuse

How to detect it

Inspect kernel logs for 'sanity_check_extent_cache' messages containing 'extent info is incorrect'; correlate with f2fs inode operations and extent cache modifications under writeback.

What your security team should do

  • Prioritize kernel upgrade on all f2fs-using systems within standard patch windows
  • Monitor for f2fs extent cache related oops or warnings in dmesg
  • Test f2fs workloads with the patched kernel before broad deployment

The record

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between extent node destroy and writeback"), and remove the unnecessary zero check of et->node_cnt.

Affected packages

Ecosystem Package Introduced Fixed