CVE-2024-35807 is a vulnerability in the Linux kernel's ext4 filesystem implementation related to on-line resizing of large ext4 filesystems. Specifically, the issue arises when performing an on-line resize operation on ext4 filesystems larger than 16 TiB with a 4k block size, where the resize_inode feature is disabled (which is the default for filesystems with more than 2^32 blocks). The vulnerability manifests as filesystem corruption during the resize process. The root cause is a logic error in the ext4_flex_group_add function, which incorrectly adds block groups that are not part of the first meta block group when converting the filesystem to use the meta block group (meta_bg) feature starting at a certain block group index (s_first_meta_bg). This leads to improper updates of backup block group descriptors, causing corruption at specific physical block locations that store metadata backups. The corruption can be reliably reproduced by creating a filesystem with resize_inode disabled, writing data, performing an on-line resize across an 8 GiB boundary (the size of a meta block group), and then verifying that the data checksum changes, indicating corruption. This vulnerability affects Linux kernel versions containing the specified commit hashes prior to the fix. The fix involves adding a check to ensure that only block groups belonging to the meta block group are added during the resize operation, preserving the integrity of metadata backups. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.

For European organizations, the impact of this vulnerability can be significant, especially for enterprises and data centers relying on large-scale Linux servers with ext4 filesystems exceeding 16 TiB. The corruption caused by on-line resizing can lead to data loss or filesystem instability, potentially disrupting critical services, applications, and data availability. Organizations performing dynamic storage resizing to accommodate growing data needs may inadvertently trigger this corruption, resulting in operational downtime and costly recovery efforts. Since ext4 is widely used in many Linux distributions common in Europe, including servers in cloud infrastructure, telecommunications, and enterprise environments, the risk is non-trivial. Although exploitation does not appear to be remotely triggered or automated, the vulnerability poses a threat during routine maintenance or scaling operations. Data integrity and availability are primarily affected, with potential secondary impacts on confidentiality if corrupted data leads to system crashes or fallback to less secure states. The absence of known exploits reduces immediate risk, but the complexity of the issue means that unnoticed corruption could silently affect systems over time.

European organizations should take the following specific mitigation steps: 1) Immediately update Linux kernels to versions containing the patch that fixes CVE-2024-35807 once available from their Linux distribution vendors. 2) Avoid performing on-line resizing operations on ext4 filesystems larger than 16 TiB with resize_inode disabled until patched. 3) If resizing is necessary, consider disabling on-line resize and performing offline resize operations with full backups in place. 4) Implement rigorous filesystem integrity checks (e.g., e2fsck) before and after resize operations to detect corruption early. 5) Maintain comprehensive backups of critical data and metadata to enable recovery in case of corruption. 6) Monitor kernel update advisories and filesystem-related bug reports closely. 7) For environments using custom or older kernels, backport the patch or apply vendor-provided fixes promptly. 8) Educate system administrators about the risks of on-line resizing on large ext4 filesystems and enforce change management controls around such operations. These measures go beyond generic advice by focusing on operational practices around resizing and filesystem integrity verification specific to this vulnerability.