lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2024051740-CVE-2024-35807-2a9e@gregkh>
Date: Fri, 17 May 2024 15:23:47 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-35807: ext4: fix corruption during on-line resize

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.

The Linux kernel CVE team has assigned CVE-2024-35807 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 4.19.312 with commit 75cc31c2e719
	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 5.4.274 with commit ee4e9c197614
	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 5.10.215 with commit e8e8b1973172
	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 5.15.154 with commit 239c669edb2b
	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 6.1.84 with commit fb1088d51bba
	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 6.6.24 with commit 37b6a3ba793b
	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 6.7.12 with commit b461910af8ba
	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 6.8.3 with commit 722d2c01b8b1
	Issue introduced in 3.7 with commit 01f795f9e0d6 and fixed in 6.9 with commit a6b3bfe176e8

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-35807
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/ext4/resize.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1
	https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c
	https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a
	https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6
	https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df
	https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5
	https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d05c6fc5c
	https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd
	https://git.kernel.org/stable/c/a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ