In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to wait dio completion
It should wait all existing dio write IOs before block removal,
otherwise, previous direct write IO may overwrite data in the
block which may be reused by other inode.
Security readout for executives and security teams
Plain-English summary
A Linux F2FS filesystem race can allow an earlier direct write to overwrite storage already reassigned to another file. This may corrupt or expose data and disrupt systems. Exploitation requires local, low-privileged access and specific concurrent filesystem activity, so internet exposure alone is insufficient.
Executive priority
Treat as a high-priority maintenance issue for systems using F2FS with untrusted local users or sensitive data. Expedite supported kernel updates after normal compatibility testing. Systems without F2FS are unlikely to be exposed based on the supplied description.
Technical view
F2FS can remove and reuse a block before all existing direct-I/O writes complete. A delayed write may then target the reused block belonging to another inode. The referenced Linux stable commits correct the ordering by waiting for direct-I/O completion before block removal. CVSS 3.1 is 7.8: local, low complexity, low privileges, no user interaction, with high confidentiality, integrity, and availability impact.
Likely exposure
Exposure is limited to Linux systems using F2FS and affected kernel code. Risk is most relevant where untrusted or compromised local users can perform filesystem operations involving direct writes. The supplied version list is ambiguous, so kernel commit or distribution-package verification is safer than relying on its version strings alone.
Exploitation context
The supplied record does not establish active exploitation, and the CVE is not identified as KEV. The CVSS vector describes a local, low-privilege attack with low complexity and no user interaction. Successful abuse still appears dependent on provoking the vulnerable direct-I/O and block-reuse timing condition.
Researcher notes
The core issue is a direct-I/O completion race during F2FS block removal and reuse, creating potential cross-inode overwrite. Six stable-kernel fix references are supplied, but the affected-version representation contains duplicates and unclear boundaries. Confirm exposure through source ancestry or distribution advisories. No CWE, public exploit, or observed exploitation evidence is provided.
Mitigation direction
Install supported kernel or distribution updates incorporating the referenced F2FS fixes.
Prioritize multi-user or tenant systems that mount F2FS and permit untrusted local access.
Consult Linux or distribution advisories to map ambiguous version data to deployed packages.
Restrict unnecessary local access until affected systems are updated.
Validation and detection
Inventory systems mounting F2FS and record their running kernel and package versions.
Compare deployed kernel commits or distribution packages against the referenced stable fixes.
Confirm updated kernels are running after installation, including following required reboots.
Monitor F2FS systems for unexplained file corruption or cross-file data inconsistencies.
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-2024-47726 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.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.