CVE-2024-42304: ext4: make sure the first directory block is not a hole
In the Linux kernel, the following vulnerability has been resolved:
ext4: make sure the first directory block is not a hole
The syzbot constructs a directory that has no dirblock but is non-inline,
i.e. the first directory block is a hole. And no errors are reported when
creating files in this directory in the following flow.
ext4_mknod
...
ext4_add_entry
// Read block 0
ext4_read_dirblock(dir, block, DIRENT)
bh = ext4_bread(NULL, inode, block, 0)
if (!bh && (type == INDEX || type == DIRENT_HTREE))
// The first directory block is a hole
// But type == DIRENT, so no error is reported.
After that, we get a directory block without '.' and '..' but with a valid
dentry. This may cause some code that relies on dot or dotdot (such as
make_indexed_dir()) to crash.
Therefore when ext4_read_dirblock() finds that the first directory block
is a hole report that the filesystem is corrupted and return an error to
avoid loading corrupted data from disk causing something bad.
Security readout for executives and security teams
Plain-English summary
CVE-2024-42304 is a Linux kernel ext4 filesystem bug. A specially malformed directory state can make kernel code trust a directory missing expected entries, leading to crashes in code paths that assume '.' and '..' exist. Business impact is most relevant for systems that mount ext4 filesystems from untrusted, damaged, or attacker-influenced storage.
Executive priority
Treat this as a kernel reliability and availability issue, not confirmed active exploitation. Patch through normal kernel maintenance, but accelerate for environments processing customer-supplied storage, forensic images, removable media, or multi-tenant workloads where malformed filesystems may be introduced.
Technical view
ext4_read_dirblock() could accept a non-inline directory whose first directory block is a hole when reading a directory entry block. Later operations may create a directory block without dot and dotdot entries but with a valid dentry, causing code such as make_indexed_dir() to crash. The kernel fix treats that condition as filesystem corruption and returns an error.
Likely exposure
Exposure is likely on Linux systems using affected kernel versions and ext4, especially where users, workloads, removable media, disk images, or recovery workflows can introduce malformed ext4 filesystems. The source lists affected kernel ranges including 5.3 through fixed stable releases such as 6.10.3, 6.6.44, 6.1.103, 5.15.165, 5.10.224, 5.4.282, and 4.19.320.
Exploitation context
The bundle attributes discovery to syzbot-style filesystem fuzzing and describes a crash condition from malformed filesystem state. It does not provide CVSS, CWE, or proof of active exploitation. KEV is false, so active exploitation should not be asserted from these sources.
Researcher notes
Key evidence is the upstream Linux kernel resolution text and stable commit references. The data lacks CVSS and detailed downstream product impact. Analysis should focus on affected kernel lineage, ext4 mounting paths, and whether downstream vendors have backported the corruption check into their supported kernels.
Mitigation direction
Update kernels through the relevant Linux distribution or vendor security channel.
Prioritize hosts that mount ext4 media, disk images, or storage from less trusted sources.
Apply Debian LTS kernel updates where those advisories match deployed systems.
Avoid mounting untrusted ext4 filesystems on unpatched production systems.
For embedded or industrial deployments, check the applicable vendor advisory before scheduling remediation.
Validation and detection
Inventory Linux kernel versions and ext4 usage across servers, endpoints, and appliances.
Confirm deployed kernels include the referenced stable ext4 fix commits or downstream backports.
Review vendor advisories for Debian LTS and any affected product-specific platforms.
Check system logs for ext4 corruption reports or crashes around directory operations.
Verify backup, recovery, and image-processing workflows do not mount untrusted ext4 filesystems unpatched.
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-42304 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.