Preface: Computing technology is advancing rapidly, and software development cycles are shrinking. Furthermore, these shorter-than-expected software development cycles are impacting vulnerability management cycles. Vulnerabilities discovered over a year ago might not be taken seriously. However, nothing in the digital world is completely secure. Therefore, it’s recommended not to ignore outdated CVE records. This topic focuses on a vulnerability discovered in December 2022. The submitter announced this vulnerability in September 2023. CVE-2023-53616 was finally published on October 4, 2025.
This article also contains other perspectives. Please enjoy!
Background: Journaled File System (JFS) is a 64-bit journaling file system created by IBM. There are versions for AIX, OS/2, eComStation, ArcaOS and Linux operating systems.
If diUnmount() writes out the inode map and the filesystem is unmounted, shouldn’t that memory be safe from reuse by attackers? Especially since it’s in kernel space and requires root privileges?
Here’s the key point:
Yes, kernel memory is protected and not directly accessible from user space. However, vulnerabilities like this are dangerous even in kernel space, because:
-Kernel code can be triggered indirectly by user actions (e.g., mounting/unmounting filesystems, accessing files).
-If a stale inode structure remains in memory and is reused without proper reinitialization, it can lead to privilege escalation or data corruption.
-Attackers with some level of access (e.g., via a compromised process or container) might exploit such bugs to gain full root access.
Can ioctl Misuse Lead to Exploitation of This Vulnerability?
Yes, absolutely. Misuse of ioctl (Input/Output Control) calls in kernel modules or drivers can be a vector for exploitation, especially when combined with vulnerabilities like the one in JFS_IP. Please see attached diagram for details.
Official announcement: Please see the link for details –