Memory Leak Affecting kernel-default package, versions <5.14.21-150400.24.133.2


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.04% (11th 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-SLES154-KERNELDEFAULT-8089783
  • published25 Sept 2024
  • disclosed24 Sept 2024

Introduced: 24 Sep 2024

CVE-2022-48890  (opens in a new tab)
CWE-401  (opens in a new tab)

How to fix?

Upgrade SLES:15.4 kernel-default to version 5.14.21-150400.24.133.2 or higher.

NVD Description

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

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

scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM

storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can't do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force.

Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.

CVSS Scores

version 3.1