CVE-2023-52444: f2fs: fix to avoid dirent corruption
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid dirent corruption
As Al reported in link[1]:
f2fs_rename()
...
if (old_dir != new_dir && !whiteout)
f2fs_set_link(old_inode, old_dir_entry,
old_dir_page, new_dir);
else
f2fs_put_page(old_dir_page, 0);
You want correct inumber in the ".." link. And cross-directory
rename does move the source to new parent, even if you'd been asked
to leave a whiteout in the old place.
[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/
With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update ".." link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar
[ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3]
[FSCK] other corrupted bugs [Fail]
Security readout for executives and security teams
Plain-English summary
A Linux F2FS filesystem flaw can corrupt directory metadata during a cross-directory rename that leaves a whiteout. Exploitation requires local access and filesystem permissions, but successful triggering may threaten data confidentiality, integrity, and availability. Systems not using F2FS are unlikely to be exposed.
Executive priority
Prioritize affected multi-user or untrusted-workload systems using F2FS. Patch through supported distribution channels on an accelerated schedule, while confirming backups and filesystem health. Lower the priority for systems demonstrably not using F2FS. No evidence in the supplied sources supports emergency response for active exploitation.
Technical view
The vulnerable F2FS rename path can fail to update the moved directory’s “..” entry when a cross-directory rename creates a whiteout. The stale parent inode reference causes directory-entry corruption detectable by filesystem checking. The supplied CVSS 3.1 score is 7.8, with local, low-privilege access required and no user interaction.
Likely exposure
Exposure is concentrated on Linux systems with F2FS filesystems where local users or workloads can perform affected rename operations. Mobile, embedded, or storage-focused deployments may warrant particular inventory attention, although the sources do not identify specific devices. The supplied version data is ambiguous, so distributor-specific status must be verified.
Exploitation context
The source bundle provides no evidence of active exploitation, and the CVE is not identified as CISA KEV-listed. Triggering is local, low complexity, and requires low privileges. The documented consequence is filesystem metadata corruption; the sources do not establish remote exploitation, public weaponization, or observed attacks.
Researcher notes
The core invariant failure is an incorrect “..” inode after moving a directory across parents while requesting a whiteout. Upstream stable commits are supplied for multiple kernel lines, but the bundle does not clearly map every affected and fixed release. Validate backports by commit or distributor advisory rather than relying solely on kernel version strings.
Mitigation direction
Install a vendor-supported kernel update containing the referenced upstream F2FS correction.
Confirm the selected distribution package backports the fix; version numbers alone may be misleading.
Where updates are delayed, limit untrusted local access to systems using F2FS.
Review Linux distributor guidance before applying additional workarounds not specified by the sources.
Validation and detection
Inventory systems with mounted or configured F2FS filesystems.
Record running kernel and package versions, then compare them with vendor security advisories.
Verify the vendor kernel includes the applicable referenced stable fix.
Assess filesystem integrity using vendor-approved procedures, especially after suspicious rename activity or errors.
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-2023-52444 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.