Loading HuntDB...
Hunt
Vulnerability Intelligence by wss.sh
Home Daily Briefings High Impact CVEs Recent Exploits KEV Catalog GitHub Advisories Latest Updates Security News
Sign In Sign Up

CVE-2021-47369

MEDIUM
Published 2024-05-21T15:03:35.149Z
Actions:

Expert Analysis

Professional remediation guidance

Get tailored security recommendations from our analyst team for CVE-2021-47369. We'll provide specific mitigation strategies based on your environment and risk profile.

CVSS Score

V3.1
5.5
/10
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Base Score Metrics
Exploitability: N/A Impact: N/A

EPSS Score

v2025.03.14
0.000
probability
of exploitation in the wild

There is a 0.0% chance that this vulnerability will be exploited in the wild within the next 30 days.

Updated: 2025-06-25
Exploit Probability
Percentile: 0.066
Higher than 6.6% of all CVEs

Attack Vector Metrics

Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED

Impact Metrics

Confidentiality
NONE
Integrity
NONE
Availability
HIGH

Description

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 <[email protected]>

Available Exploits

No exploits available for this CVE.

Related News

No news articles found for this CVE.

Affected Products

Linux

Linux

Affected Versions:

eff73e16ee116f6eafa2be48fab42659a27cb453 eff73e16ee116f6eafa2be48fab42659a27cb453 eff73e16ee116f6eafa2be48fab42659a27cb453 b2400fe7e1011c5f3dc2268e8382082465b1c8a2 22697ca855c06a4a1264d5651542b7d98870a8c4
Linux

Linux

Affected Versions:

5.9 0 5.10.70 5.14.9 5.15
linux

linux_kernel

Affected Versions:

eff73e16ee11
linux

linux_kernel

Affected Versions:

eff73e16ee11
linux

linux_kernel

Affected Versions:

eff73e16ee11
linux

linux_kernel

Affected Versions:

5.9
linux

linux_kernel

Affected Versions:

0
linux

linux_kernel

Affected Versions:

5.10.70
linux

linux_kernel

Affected Versions:

5.14.9
linux

linux_kernel

Affected Versions:

5.15

GitHub Security Advisories

Community-driven vulnerability intelligence from GitHub

⚠ Unreviewed MODERATE

GHSA-hq29-fr4v-2847

Advisory Details

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 <[email protected]>

CVSS Scoring

CVSS Score

5.0

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

References

ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2021-47369
WEB https://git.kernel.org/stable/c/248f064af222a1f97ee02c84a98013dfbccad386
WEB https://git.kernel.org/stable/c/9b00fb12cdc9d8d1c3ffe82a78e74738127803fc
WEB https://git.kernel.org/stable/c/db94f89e1dadf693c15c2d60de0c34777cea5779

Advisory provided by GitHub Security Advisory Database. Published: May 21, 2024, Modified: July 3, 2024

References

https://git.kernel.org/stable/c/db94f89e1dadf693c15c2d60de0c34777cea5779
https://git.kernel.org/stable/c/9b00fb12cdc9d8d1c3ffe82a78e74738127803fc
https://git.kernel.org/stable/c/248f064af222a1f97ee02c84a98013dfbccad386
Published: 2024-05-21T15:03:35.149Z
Last Modified: 2025-05-07T19:56:25.701Z
Copied to clipboard!