CVE-2025-37785 is a vulnerability in the Linux kernel's ext4 filesystem implementation, specifically related to directory entry parsing during filesystem mounting and directory removal operations. The flaw arises when mounting a corrupted ext4 filesystem containing a directory with a '.' entry whose record length (rec_len) is exactly equal to the block size (typically 4KB). The ext4_empty_dir() function assumes that every directory contains at least '.' and '..' entries within the first data block and uses the rec_len of '.' to locate the '..' entry. However, if '.' has a rec_len equal to the block size, it passes sanity checks incorrectly, causing the pointer for the '..' entry to point just beyond the allocated memory block. Subsequent dereferencing of this pointer leads to an out-of-bounds (OOB) read. This OOB read can result in undefined behavior, including potential kernel crashes or information disclosure. The issue was detected by the syzkaller fuzzing tool and reported as a use-after-free by KASAN, though it is fundamentally an OOB read. The vulnerability is triggered during mounting or when removing the corrupted directory, involving functions ext4_empty_dir() and ext4_rmdir(). The root cause is insufficient validation of directory entry boundaries in ext4_check_dir_entry(), which has been addressed by adding checks to detect '.' entries that extend to the end of the data block and ignoring phony entries used for checksumming. This vulnerability affects Linux kernel versions including commit ac27a0ec112a089f1a5102bc8dffc79c8c815571 and likely others around that timeframe. No known exploits are reported in the wild as of publication. The vulnerability requires a specially crafted corrupted ext4 filesystem image to trigger, implying an attacker needs to supply or mount such a filesystem to exploit it. The impact is primarily on kernel stability and potential information leakage due to OOB reads during filesystem operations.

For European organizations, this vulnerability poses a risk primarily to systems running Linux with ext4 filesystems, which is the default filesystem for many Linux distributions widely used in enterprise, government, and cloud environments across Europe. The OOB read could lead to kernel crashes (denial of service) or potentially expose sensitive kernel memory contents, risking confidentiality breaches. Systems that mount external or untrusted ext4 filesystems, such as removable media, network shares, or virtual machine disk images, are particularly at risk. This could affect servers, desktops, embedded devices, and cloud infrastructure. Disruption of critical services due to kernel panics or crashes could impact business continuity, especially in sectors like finance, healthcare, telecommunications, and public administration. Although exploitation requires mounting a corrupted filesystem, the complexity is moderate for attackers with local or physical access or those able to convince users or administrators to mount malicious filesystems. The lack of known exploits reduces immediate risk, but the vulnerability should be addressed promptly to prevent future exploitation. The vulnerability does not directly allow privilege escalation or remote code execution but could be leveraged as part of a multi-stage attack chain. Overall, the impact on confidentiality, integrity, and availability is significant enough to warrant urgent mitigation in European organizations relying on Linux ext4 filesystems.

1. Apply the official Linux kernel patches that fix this vulnerability as soon as they become available from trusted sources or Linux distribution vendors. 2. Avoid mounting untrusted or suspicious ext4 filesystems, especially those received from external or unknown sources, until patched. 3. Implement strict controls and validation on removable media and network-shared filesystems to prevent mounting of corrupted or malicious ext4 images. 4. Use filesystem integrity checking tools to detect and quarantine corrupted ext4 filesystems before mounting. 5. For virtualized environments, ensure that virtual disk images are scanned and validated prior to use. 6. Employ kernel hardening and runtime protection mechanisms such as Kernel Address Sanitizer (KASAN) in testing environments to detect similar issues early. 7. Monitor system logs for kernel warnings or crashes related to ext4 operations that could indicate attempted exploitation. 8. Educate system administrators about the risks of mounting untrusted filesystems and enforce policies restricting such actions. 9. Consider deploying layered security controls such as SELinux or AppArmor profiles to limit the impact of kernel-level faults. 10. Maintain up-to-date backups and disaster recovery plans to mitigate potential service disruptions caused by kernel crashes.