CVE-2024-35807

MEDIUM
Published May 17, 2024 Modified May 12, 2026

Description

In the Linux kernel, the following vulnerability has been resolved: ext4: fix corruption during on-line resize We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not.

Is your site exposed to CVE-2024-35807?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

5.5
MEDIUM
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected Products

Vendor Product
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
debian debian_linux

References

Advisories & Patches

https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6 https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5 https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1 https://git.kernel.org/stable/c/a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d05c6fc5c https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6 https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5 https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1 https://git.kernel.org/stable/c/a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d05c6fc5c https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df

Frequently Asked Questions

What is CVE-2024-35807? +
In the Linux kernel, the following vulnerability has been resolved: ext4: fix corruption during on-line resize We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. It has a CVSS v3.1 base score of 5.5 (MEDIUM).
How severe is CVE-2024-35807? +
CVE-2024-35807 has a CVSS v3.1 score of 5.5 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance.
What products are affected by CVE-2024-35807? +
CVE-2024-35807 affects products from debian, linux, specifically: debian_linux, linux_kernel. Check the affected products table above for specific version ranges.
How do I check if I'm vulnerable to CVE-2024-35807? +
You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2025-9588 10.0

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Iron Mountain Archiving Services Inc. …
CVE-2025-57870 10.0

A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This …
CVE-2026-48286 10.0

Adobe Campaign Classic (ACC) versions 7.4.3 build 9396 and earlier are affected by an Incorrect Authorization vulnerability that could result …
CVE-2026-13782 10.0

Use after free in Browser in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer …
CVE-2026-48449 10.0

Adobe Campaign Classic (ACC) is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the …
CVE-2026-48303 10.0

Adobe Campaign Classic (ACC) versions 7.4.3 build 9394 and earlier are affected by an Incorrect Authorization vulnerability that could result …

Don't wait for an exploit

Scan your website for vulnerabilities like CVE-2024-35807 — free, no signup required.