Memory Leak Affecting kernel-64kb package, versions <5.3.18-150300.59.158.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.05% (18th 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 Learn

Learn about Memory Leak vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES153-KERNEL64KB-7722150
  • published20 Aug 2024
  • disclosed3 May 2024

Introduced: 3 May 2024

CVE-2021-47119  (opens in a new tab)
CWE-401  (opens in a new tab)

How to fix?

Upgrade SLES:15.3 kernel-64kb to version 5.3.18-150300.59.158.1 or higher.

NVD Description

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

In the Linux kernel, the following vulnerability has been resolved:

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.

CVSS Scores

version 3.1