CVE-2021-47369 Affecting kernel-64kb-devel package, versions <5.14.21-150400.24.122.2


Severity

Recommended
medium

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 IDSNYK-SLES154-KERNEL64KBDEVEL-7373903
  • published26 Jun 2024
  • disclosed25 Jun 2024

Introduced: 25 Jun 2024

CVE-2021-47369  (opens in a new tab)

How to fix?

Upgrade SLES:15.4 kernel-64kb-devel to version 5.14.21-150400.24.122.2 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-64kb-devel package and not the kernel-64kb-devel 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:

s390/qeth: fix NULL deref in qeth_clear_working_pool_list()

When qeth_set_online() calls qeth_clear_working_pool_list() to roll back after an error exit from qeth_hardsetup_card(), we are at risk of accessing card->qdio.in_q before it was allocated by qeth_alloc_qdio_queues() via qeth_mpc_initialize().

qeth_clear_working_pool_list() then dereferences NULL, and by writing to queue->bufs[i].pool_entry scribbles all over the CPU's lowcore. Resulting in a crash when those lowcore areas are used next (eg. on the next machine-check interrupt).

Such a scenario would typically happen when the device is first set online and its queues aren't allocated yet. An early IO error or certain misconfigs (eg. mismatched transport mode, bad portno) then cause us to error out from qeth_hardsetup_card() with card->qdio.in_q still being NULL.

Fix it by checking the pointer for NULL before accessing it.

Note that we also have (rare) paths inside qeth_mpc_initialize() where a configuration change can cause us to free the existing queues, expecting that subsequent code will allocate them again. If we then error out before that re-allocation happens, the same bug occurs.

Root-caused-by: Heiko Carstens <hca@linux.ibm.com>

CVSS Scores

version 3.1