ACK/Cmnt: [SRU][F:linux]PATCH v2 0/1] CVE-2021-47119
Koichiro Den
koichiro.den at canonical.com
Thu Feb 20 01:57:16 UTC 2025
On Tue, Feb 18, 2025 at 12:15:31PM GMT, Andrei Gherzan wrote:
> [Impact]
>
> ext4: fix memory leak in ext4_fill_super
>
> Buffer head references must be released before calling kill_bdev();
> otherwise the buffer head (and its page referenced by b_data) will not
> be freed by kill_bdev, and subsequently that bh will be leaked.
>
> If blocksizes differ, sb_set_blocksize() will kill current buffers and
> page cache by using kill_bdev(). And then super block will be reread
> again but using correct blocksize this time. sb_set_blocksize() didn't
> fully free superblock page and buffer head, and being busy, they were
> not freed and instead leaked.
>
> This can easily be reproduced by calling an infinite loop of:
>
> systemctl start <ext4_on_lvm>.mount, and
> systemctl stop <ext4_on_lvm>.mount
>
> ... since systemd creates a cgroup for each slice which it mounts, and
> the bh leak get amplified by a dying memory cgroup that also never
> gets freed, and memory consumption is much more easily noticed.
>
> [Backport]
>
> oracular: Not affected
> noble: Not affected
> jammy: Not affected
> focal: Fix had to be backported due to fcrypt support for
> test_dummy_encryption=v2 introduced in 5.8.
> bionic: Fix sent to the ESM mailing list.
> xenial: Fix sent to the ESM mailing list.
> trusty: Fix sent to the ESM mailing list.
>
>
> [Test Case]
>
> * Compiled the kernels with the fix.
> * Booted the packages with the fix.
> * Exercised with a series of ext4 mounts and umounts.
>
> [Where problems could occur]
>
> Issues might appear in the ext4 filesystem.
>
> v2: Fixed the git message footer's patch provenance
>
> Alexey Makhalov (1):
> ext4: fix memory leak in ext4_fill_super
>
> fs/ext4/super.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
The title should be "[SRU][F][PATCH v2 0/1] CVE-2021-47119".
Other than, LGTM.
Acked-by: Koichiro Den <koichiro.den at canonical.com>
More information about the kernel-team
mailing list