CVE-2026-46194: f2fs: fix node_cnt race between extent node destroy and writeback
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix node_cnt race between extent node destroy and writeback
f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing
extent nodes. When called from f2fs_drop_inode() with I_SYNC set,
concurrent kworker writeback can insert new extent nodes into the same
extent tree, racing with the destroy and triggering f2fs_bug_on() in
__destroy_extent_node(). The scenario is as follows:
drop inode writeback
- iput
- f2fs_drop_inode // I_SYNC set
- f2fs_destroy_extent_node
- __destroy_extent_node
- while (node_cnt) {
write_lock(&et->lock)
__free_extent_tree
write_unlock(&et->lock)
- __writeback_single_inode
- f2fs_outplace_write_data
- f2fs_update_read_extent_cache
- __update_extent_tree_range
// FI_NO_EXTENT not set,
// insert new extent node
} // node_cnt == 0, exit while
- f2fs_bug_on(node_cnt) // node_cnt > 0
Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for
EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected.
This patch set FI_NO_EXTENT under et->lock in __destroy_extent_node(),
consistent with other callers (__update_extent_tree_range and
__drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and
EX_BLOCK_AGE tree.
Security readout for executives and security teams
Plain-English summary
This Linux kernel f2fs flaw is a race in filesystem cleanup and writeback. Affected systems using f2fs could hit an internal kernel assertion during inode drop while writeback updates extent caches. The public record does not provide CVSS, confirmed exploit activity, or attacker prerequisites, so urgency depends on whether f2fs is used on production kernels in the affected ranges.
Executive priority
Treat this as a targeted kernel reliability issue until more severity data exists. Prioritize environments using f2fs, especially production systems where kernel assertion failures could affect service availability. Do not escalate as actively exploited based on the current source bundle.
Technical view
f2fs_destroy_extent_node() cleared extent nodes without setting FI_NO_EXTENT under et->lock. Concurrent writeback could insert new extent nodes into the same tree, leaving node_cnt nonzero and triggering f2fs_bug_on(). The fix sets FI_NO_EXTENT during destroy and checks it for both EX_READ and EX_BLOCK_AGE updates.
Likely exposure
Exposure appears limited to Linux systems running affected kernels where f2fs is enabled and used. The bundle lists Linux as affected, but version data is commit/range-oriented and should be reconciled against distribution kernel advisories before scoping production impact.
Exploitation context
The source bundle reports no KEV listing and provides no evidence of active exploitation. It describes a race condition reachable through kernel filesystem behavior, not a documented remote attack path. Attacker requirements, privilege level, and practical exploitability are not established in the provided sources.
Researcher notes
Key race is between f2fs_destroy_extent_node() and writeback-driven __update_extent_tree_range(). The stated fix aligns destroy behavior with other FI_NO_EXTENT users and extends protection beyond EX_READ to EX_BLOCK_AGE. The bundle lacks CVSS, CWE, exploitability analysis, and distribution-specific fixed versions.
Mitigation direction
Inventory Linux hosts using f2fs filesystems.
Map kernel versions to vendor or distribution fixed builds.
Prioritize updating affected kernels to versions containing the referenced stable fixes.
If no packaged fix exists, monitor vendor kernel guidance closely.
Avoid assuming non-f2fs hosts are exposed without verification.
Validation and detection
Check whether f2fs is mounted or configured on each Linux host.
Record exact running kernel versions and downstream package revisions.
Compare kernels against vendor advisories and referenced stable commits.
Review crash logs for f2fs_bug_on or extent-tree failures.
Confirm remediation after reboot into the updated kernel.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-46194 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 28, 2026, 09:36 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.