CVE-2024-42305: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: ext4: check dot and dotdot of dx_root before making dir indexed Syzbot reports a issue as follows: ============================================ BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================ The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295] The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called. But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows: bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024 So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called. In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1. Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.
AI Analysis
Technical Summary
CVE-2024-42305 is a vulnerability identified in the Linux kernel's ext4 filesystem implementation, specifically within the directory indexing (dx) feature. The flaw arises during the handling of directory entries (dentries) in the ext4 filesystem when converting a directory to an indexed format. The vulnerability is triggered by an abnormal condition where the directory lacks the mandatory '.' (dot) and '..' (dotdot) entries, which are normally the first two entries in any directory. This abnormal state was discovered through Syzbot fuzzing, which generated a crafted filesystem image missing these entries. The kernel code assumes the presence of these entries and uses them to manage the directory index root (dx_root). When these entries are missing, the function make_indexed_dir() incorrectly processes the directory entries, leading to a count of only one valid dentry during the splitting operation in do_split(). This causes an out-of-bounds access when the code attempts to access map[split - 1], where split is zero, resulting in a page fault and kernel oops (crash). The root cause is that the code does not validate the dot and dotdot entries before proceeding with the directory indexing conversion, leading to unsafe memory access. The patch involves adding a helper function ext4_check_dx_root() to perform sanity checks on these entries before conversion, preventing the out-of-bounds access. This vulnerability affects Linux kernel versions around 6.10.0-rc5 and potentially others using the ext4 filesystem with directory indexing enabled. Exploitation requires crafted filesystem images or manipulation of directory entries, which could be triggered locally or via malicious mounts. No known exploits are reported in the wild yet.
Potential Impact
For European organizations, this vulnerability poses a risk primarily to systems running Linux with ext4 filesystems, which is common in servers, desktops, and embedded devices. The impact includes potential denial of service (DoS) through kernel crashes caused by out-of-bounds memory access, leading to system instability or downtime. In environments where Linux servers handle critical workloads or sensitive data, such crashes could disrupt services and impact business continuity. Although the vulnerability does not directly indicate privilege escalation or remote code execution, kernel crashes can be leveraged by attackers to cause persistent denial of service or potentially aid in further exploitation chains. Organizations relying on Linux-based infrastructure, including cloud providers, web hosting, and enterprise servers, may be affected if they mount or interact with maliciously crafted ext4 filesystems. The absence of known exploits suggests limited immediate threat, but the complexity of the vulnerability and its kernel-level nature warrant prompt attention to avoid future exploitation. Additionally, embedded devices and IoT systems using ext4 may be vulnerable, potentially impacting industrial or critical infrastructure sectors in Europe.
Mitigation Recommendations
1. Apply the official Linux kernel patches that include the ext4_check_dx_root() helper function to validate directory entries before indexing conversion. Ensure all Linux systems are updated to kernel versions that contain this fix. 2. For systems unable to update immediately, avoid mounting untrusted or suspicious ext4 filesystems, especially those received from external or unknown sources. 3. Implement strict filesystem integrity checks and monitoring to detect anomalies in directory structures, particularly missing dot and dotdot entries. 4. Use kernel hardening features such as Kernel Address Sanitizer (KASAN) and Kernel Page Table Isolation (KPTI) to reduce the risk and impact of memory corruption vulnerabilities. 5. Employ containerization or sandboxing to limit the impact of potential kernel crashes on critical services. 6. Maintain regular backups and disaster recovery plans to mitigate downtime caused by unexpected kernel panics. 7. Monitor security advisories and vulnerability databases for updates or emerging exploits related to CVE-2024-42305.
Affected Countries
Germany, France, United Kingdom, Netherlands, Italy, Spain, Poland, Sweden, Belgium, Finland
CVE-2024-42305: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: ext4: check dot and dotdot of dx_root before making dir indexed Syzbot reports a issue as follows: ============================================ BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================ The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295] The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called. But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows: bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024 So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called. In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1. Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.
AI-Powered Analysis
Technical Analysis
CVE-2024-42305 is a vulnerability identified in the Linux kernel's ext4 filesystem implementation, specifically within the directory indexing (dx) feature. The flaw arises during the handling of directory entries (dentries) in the ext4 filesystem when converting a directory to an indexed format. The vulnerability is triggered by an abnormal condition where the directory lacks the mandatory '.' (dot) and '..' (dotdot) entries, which are normally the first two entries in any directory. This abnormal state was discovered through Syzbot fuzzing, which generated a crafted filesystem image missing these entries. The kernel code assumes the presence of these entries and uses them to manage the directory index root (dx_root). When these entries are missing, the function make_indexed_dir() incorrectly processes the directory entries, leading to a count of only one valid dentry during the splitting operation in do_split(). This causes an out-of-bounds access when the code attempts to access map[split - 1], where split is zero, resulting in a page fault and kernel oops (crash). The root cause is that the code does not validate the dot and dotdot entries before proceeding with the directory indexing conversion, leading to unsafe memory access. The patch involves adding a helper function ext4_check_dx_root() to perform sanity checks on these entries before conversion, preventing the out-of-bounds access. This vulnerability affects Linux kernel versions around 6.10.0-rc5 and potentially others using the ext4 filesystem with directory indexing enabled. Exploitation requires crafted filesystem images or manipulation of directory entries, which could be triggered locally or via malicious mounts. No known exploits are reported in the wild yet.
Potential Impact
For European organizations, this vulnerability poses a risk primarily to systems running Linux with ext4 filesystems, which is common in servers, desktops, and embedded devices. The impact includes potential denial of service (DoS) through kernel crashes caused by out-of-bounds memory access, leading to system instability or downtime. In environments where Linux servers handle critical workloads or sensitive data, such crashes could disrupt services and impact business continuity. Although the vulnerability does not directly indicate privilege escalation or remote code execution, kernel crashes can be leveraged by attackers to cause persistent denial of service or potentially aid in further exploitation chains. Organizations relying on Linux-based infrastructure, including cloud providers, web hosting, and enterprise servers, may be affected if they mount or interact with maliciously crafted ext4 filesystems. The absence of known exploits suggests limited immediate threat, but the complexity of the vulnerability and its kernel-level nature warrant prompt attention to avoid future exploitation. Additionally, embedded devices and IoT systems using ext4 may be vulnerable, potentially impacting industrial or critical infrastructure sectors in Europe.
Mitigation Recommendations
1. Apply the official Linux kernel patches that include the ext4_check_dx_root() helper function to validate directory entries before indexing conversion. Ensure all Linux systems are updated to kernel versions that contain this fix. 2. For systems unable to update immediately, avoid mounting untrusted or suspicious ext4 filesystems, especially those received from external or unknown sources. 3. Implement strict filesystem integrity checks and monitoring to detect anomalies in directory structures, particularly missing dot and dotdot entries. 4. Use kernel hardening features such as Kernel Address Sanitizer (KASAN) and Kernel Page Table Isolation (KPTI) to reduce the risk and impact of memory corruption vulnerabilities. 5. Employ containerization or sandboxing to limit the impact of potential kernel crashes on critical services. 6. Maintain regular backups and disaster recovery plans to mitigate downtime caused by unexpected kernel panics. 7. Monitor security advisories and vulnerability databases for updates or emerging exploits related to CVE-2024-42305.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-07-30T07:40:12.273Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9828c4522896dcbe1eca
Added to database: 5/21/2025, 9:08:56 AM
Last enriched: 6/29/2025, 7:09:29 AM
Last updated: 8/11/2025, 3:45:11 AM
Views: 12
Related Threats
CVE-2025-25229: Vulnerability in Omnissa Omnissa Workspace ONE UEM
MediumCVE-2025-25231: Vulnerability in Omnissa Omnissa Workspace ONE UEM
HighCVE-2025-53187: CWE-94 Improper Control of Generation of Code ('Code Injection') in ABB ASPECT
HighCVE-2025-54063: CWE-94: Improper Control of Generation of Code ('Code Injection') in CherryHQ cherry-studio
HighCVE-2025-1500: CWE-434 Unrestricted Upload of File with Dangerous Type in IBM Maximo Application Suite
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.