Homepage

CVE-2024-35807 Affecting kernel-rt package, versions *

Severity

 Recommended
0.0
medium
0
10

Based on CentOS security rating.

Threat Intelligence

EPSS
0.04% (15th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS7-KERNELRT-6879481
  • published18 May 2024
  • disclosed17 May 2024
Report a new vulnerability Found a mistake?

Introduced: 17 May 2024

CVE-2024-35807  (opens in a new tab)

How to fix?

There is no fixed version for Centos:7 kernel-rt.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-rt package and not the kernel-rt package as distributed by Centos. See How to fix? for Centos:7 relevant fixed versions and status.

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 * 221 - 215)) mount -t ext4 $dev /corruption

dd if=/dev/zero bs=4096 of=/corruption/test count=$((22**21 - 42**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.

References

CVSS Scores

version 3.1