Bug 2502236 (CVE-2026-63812) - CVE-2026-63812 kernel: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()
Summary: CVE-2026-63812 kernel: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy...
Keywords:
Status: NEW
Alias: CVE-2026-63812
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-07-19 13:03 UTC by OSIDB Bzimport
Modified: 2026-07-20 15:31 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-07-19 13:03:19 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.