CVE-2023-52444

What it actually does

f2fs_rename() in the Linux kernel fails to call f2fs_set_link() to update the ".." entry when performing a cross-directory rename that also creates a whiteout, leaving the directory entry with an incorrect parent inode number and causing dirent corruption.

Why it matters to the business

Local users on systems using the f2fs filesystem can trigger directory corruption that leads to filesystem inconsistency, failed fsck repairs, and potential data inaccessibility; the issue has been public for over two years with no known active exploitation.

How an attack unfolds

An attacker with local access on an f2fs volume creates a nested directory structure and then invokes renameat2 with the whiteout flag to move the source directory into a different parent; the missing ".." update leaves an invalid inode reference that fsck later flags as corruption.

How to fix it

Upgrade the Linux kernel to a version containing commit 02160112e6d45c2610b049df6eb693d7a2e57b46 or later; rebuild and reboot with the fixed kernel, then run fsck.f2fs on affected volumes to verify directory integrity.

How to confirm the fix worked

Confirm the running kernel contains commit 02160112e6d45c2610b049df6eb693d7a2e57b46; create the repro directory layout and run fsck.f2fs to ensure no "Bad inode number for '..'" assertions occur.

Typical attack path

1. mkdir -p dir/foo on an f2fs mount
2. renameat2 -w dir/foo bar
3. trigger fsck or directory traversal that reads the corrupted ".." entry

How to detect it

Scan kernel logs and fsck output for "Bad inode number for '..'" or "__chk_dots_dentries" assertions; examine audit logs for renameat2 calls with the RENAME_WHITEOUT flag on f2fs mounts.

What your security team should do

• Patch all f2fs-using systems to the fixed kernel commit immediately
• Add f2fs filesystem mounts to routine fsck monitoring
• Review local unprivileged user access policies on systems hosting f2fs volumes