CVE-2024-42305: ext4: check dot and dotdot of dx_root before making dir indexed
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.
Security readout for executives and security teams
Plain-English summary
CVE-2024-42305 is a Linux kernel ext4 filesystem bug. A malformed or corrupted ext4 directory can trigger a kernel fault when the kernel converts a directory to an indexed format. The public sources describe a crash condition found by syzbot, not confirmed real-world exploitation.
Executive priority
Treat as a normal-priority kernel maintenance issue unless your environment mounts untrusted filesystem images. There is no source-backed active exploitation signal, but kernel crash risk justifies timely patching through standard update channels.
Technical view
The flaw is in ext4 directory indexing. A crafted ext4 image missing valid dot and dotdot entries can leave only one valid entry for splitting, causing an out-of-bounds map access in do_split through make_indexed_dir during rename handling. Stable fixes add ext4_check_dx_root sanity checks before conversion.
Likely exposure
Exposure is most relevant on affected Linux kernels using ext4, especially systems that mount or process untrusted, removable, or user-provided filesystem images. The bundle does not prove remote reachability or broad internet exposure.
Exploitation context
The source evidence is syzbot-triggered with a crafted filesystem image. CISA KEV is false in the bundle, and no cited source states active exploitation. Practical abuse likely depends on the ability to introduce or mount malformed ext4 content.
Researcher notes
Severity, CVSS, and CWE are absent from the bundle. The affected range is broad, but fixed commits are available across stable branches. Analysis should focus on vendor kernel mapping, ext4 exposure, and whether untrusted filesystem images can reach production hosts.
Mitigation direction
Update affected Linux kernels using vendor-supported packages or stable kernel fixes.
Apply relevant Debian LTS kernel updates where Debian systems are in scope.
Restrict mounting or processing untrusted ext4 images and removable media.
Check Siemens guidance for affected appliances or products before assuming coverage.
Validation and detection
Inventory Linux kernel versions and compare them with vendor fixed releases.
Confirm ext4 is used on systems that handle untrusted media or disk images.
Review kernel package changelogs for the referenced ext4 dx_root fix.
Verify Debian LTS systems received the cited security updates.
Track vendor advisories for embedded or appliance kernels.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-42305 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.