Memory Leak Affecting kernel-64kb package, versions <5.14.21-150500.55.80.2


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.04% (12th 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-SLES155-KERNEL64KB-8103914
  • published28 Sept 2024
  • disclosed27 Sept 2024

Introduced: 27 Sep 2024

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

How to fix?

Upgrade SLES:15.5 kernel-64kb to version 5.14.21-150500.55.80.2 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.5 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