CVE-2023-52603 - Linux Kernel dtSplitRoot Out-Of-Bounds Vulnerability Explained
Security flaws in the Linux kernel can have major consequences, especially when they’re buried deep in seldom-used filesystems. One such vulnerability—tracked as CVE-2023-52603—surfaced in the implementation of IBM's JFS (Journaled File System). This bug was flagged by Google's automated fuzzing tool Syzkaller and concerns an *array index out-of-bounds* in the dtSplitRoot() function, potentially leading to kernel crashes or worse. In this article, we’ll break down what happened, how it was fixed, and walk through real kernel code snippets and exploit details in simple terms.
The problem was reported as follows
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type 'struct dtslot [128]'
This tells us that somewhere in the code, an array was being accessed with a negative index (-2). In most programming languages, this is a serious error—a way to potentially read or write memory you shouldn’t.
Key Points
- Affected Component: dtSplitRoot function in fs/jfs/jfs_dtree.c
Technical Breakdown
Let’s examine the code and the specifics of the bug.
The heart of the issue is in dtSplitRoot()
struct dtslot slot[128];
// ... other code ...
fsi--; // decrement fsi, with risk it can go below
// Some safeguard only for -1
if (fsi == -1)
break;
// This access can be negative when fsi < :
some_var = slot[fsi];
As you can see, if fsi (the array index variable) ever becomes *less than -1*, the safeguard fails. An attacker could cause this through repeated directory operations, causing an out-of-bounds read or write.
The bug was reproducible with Syzkaller, and the kernel log looked like this
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type 'struct dtslot [128]'
CPU: PID: 3613 Comm: syz-executor270 Not tainted ...
Call Trace:
dtSplitRoot+x8d8/x190 fs/jfs/jfs_dtree.c:1971
dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
dtInsert+x1189/x6b80 fs/jfs/jfs_dtree.c:863
jfs_mkdir+x757/xb00 fs/jfs/namei.c:270
vfs_mkdir+x3b3/x590 fs/namei.c:4013
do_mkdirat+x279/x550 fs/namei.c:4038
...
Exploitation Details
While JFS is not commonly used compared to ext4 or xfs, this vulnerability presents a classic kernel attack surface. Here’s how a malicious user could exploit it:
1. Prepare a JFS-formatted filesystem image
mkfs.jfs /dev/loopX
mount -t jfs /dev/loopX /mnt/test
2. Repeatedly perform directory creation with crafted parameters
Attackers can use fuzzing or handcrafted syscalls (with out-of-range, corrupted, or unexpected directory names) to try to trigger the bug—Syzkaller does this automatically using random inputs to kernel syscalls.
#include <unistd.h>
#include <sys/syscall.h>
#define SYS_mkdirat 258
int main() {
syscall(SYS_mkdirat, 3, "/mnt/test/exploit", );
// ...repeat, or fuzz inputs...
return ;
}
3. Impact
- Local Denial of Service (system crash/panic)
- Potential Out-of-Bounds Memory Read/Write: In theory, a skilled attacker may elevate from a crash to code execution, though no public exploit for privilege escalation exists as of June 2024.
The Patch: How did the Kernel Team Fix It?
The vulnerable code originally only checked for fsi == -1. The patch expanded this to ensure *no negative values* are permitted.
Before
if (fsi == -1)
break;
After (Patched)
if (fsi < )
break;
Full Patch Reference:
- Mainline Linux Commit
- Syzbot Report
How does this help?
By blocking the index from dipping below zero, the kernel avoids ever accessing slot -2 or other negative indexes, thus preventing the vulnerability.
Further References
- https://nvd.nist.gov/vuln/detail/CVE-2023-52603
- Upstream Patch
- Syzbot Report and Discussion
Conclusion
While this vulnerability primarily concerns legacy JFS setups, it’s a reminder that old filesystem code can harbor severe bugs. Thanks to automatic tools and diligent maintainers, the fix was simple but vital. If you run a Linux system (especially with JFS), update your kernel to stay protected.
For system administrators and developers: always keep up to date, and pay attention to kernel patch logs—even on less popular filesystems!
Timeline
Published on: 03/06/2024 07:15:11 UTC
Last modified on: 12/12/2024 17:36:56 UTC