CVE-2024-58240
Description
From CVE.org
In the Linux kernel, the following vulnerability has been resolved: tls: separate no-async decryption request handling from async If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result. We should preferably also use a separate crypto_wait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it. This will make the next fix easier.
Statement
This patch refactors TLS RX decryption to use a separate, stack-local crypto_wait for the non-async path and bypass the async reference-counting/notification logic. It doesn’t fix a user-triggerable bug by itself; it’s a correctness/simplification change that reduces coupling and prepares the ground for a follow-up fix (“tls: fix use-after-free on failed backlog decryption”). No externally exploitable behavior changes are introduced. The bug is actual for the older versions of Red Hat Enterprise Linux (before 9.3 and for all versions of the Red Hat Enterprise Linux 8) where patch aec7961916f3 "tls: fix race between async notify and socket close" not backported yet. The CVSS being calculated for worse case scenario where the previous patch aec7961916f3 not applied yet (that leads to the use after free possibility).
Mitigation
To mitigate this issue, prevent module tls from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.3 | 7.8 | 9.8 |
| Attack Vector | Network | Local | Network |
| Attack Complexity | Low | Low | Low |
| Privileges Required | None | Low | None |
| User Interaction | None | None | None |
| Scope | Unchanged | Unchanged | Unchanged |
| Confidentiality | Low | High | High |
| Integrity Impact | Low | High | High |
| Availability Impact | Low | High | High |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
NVD: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
cve.org: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Understanding the Weakness (CWE)
Integrity
Technical Impact: Modify Memory
The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere.
Availability
Technical Impact: DoS: Crash, Exit, or Restart
If chunk consolidation occurs after the use of previously freed data, the process may crash when invalid data is used as chunk information.
Confidentiality
Technical Impact: Read Memory
Read operations on freed memory can sometimes leak sensitive information instead of causing a crash
Integrity,Confidentiality,Availability
Technical Impact: Execute Unauthorized Code or Commands
If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
