CVE-2024-58240
published 2025-08-28CVE-2024-58240: 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…
PriorityP336high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.15%
5.0th percentile
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.
Affected
18 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | debian_linux | — | — |
| debian | linux | < linux 6.1.153-1 (bookworm) | linux 6.1.153-1 (bookworm) |
| debian | linux-6.1 | < linux 6.1.153-1 (bookworm) | linux 6.1.153-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 3c4d7559159bfe1e3b94df3a657b2cda3a34e218 < 48905146d11dbf1ddbb2967319016a83976953f5 | 48905146d11dbf1ddbb2967319016a83976953f5 |
| linux | linux | >= 3c4d7559159bfe1e3b94df3a657b2cda3a34e218 < dec5b6e7b211e405d3bcb504562ab21aa7e5a64d | dec5b6e7b211e405d3bcb504562ab21aa7e5a64d |
| linux | linux | >= 3c4d7559159bfe1e3b94df3a657b2cda3a34e218 < 999115298017a675d8ddf61414fc7a85c89f1186 | 999115298017a675d8ddf61414fc7a85c89f1186 |
| linux | linux | >= 3c4d7559159bfe1e3b94df3a657b2cda3a34e218 < 41532b785e9d79636b3815a64ddf6a096647d011 | 41532b785e9d79636b3815a64ddf6a096647d011 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.153-1 | 6.1.153-1 |
| linux | linux_kernel | >= 0 < 6.7.9-1 | 6.7.9-1 |
| linux | linux_kernel | >= 0 < 6.7.9-1 | 6.7.9-1 |
| linux | linux_kernel | >= 4.13 < 6.1.149 | 6.1.149 |
| linux | linux_kernel | >= 6.2 < 6.6.21 | 6.6.21 |
| linux | linux_kernel | >= 6.7 < 6.7.9 | 6.7.9 |
| msrc | cbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0 | — | — |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8HIGH
vendor_msrc7.8HIGH
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2024-58240: In the Linux kernel, the following vulnerability has been resolved: tls: separate no-async decryption request handling from async If we're not doing a
osv·2025-08-28·CVSS 7.8
CVE-2024-58240 [HIGH] CVE-2024-58240: In the Linux kernel, the following vulnerability has been resolved: tls: separate no-async decryption request handling from async If we're not doing a
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.
GHSA
GHSA-fpx7-665w-c5c9: In the Linux kernel, the following vulnerability has been resolved:
tls: separate no-async decryption request handling from async
If we're not doing
ghsa_unreviewed·2025-08-28
CVE-2024-58240 [HIGH] CWE-416 GHSA-fpx7-665w-c5c9: In the Linux kernel, the following vulnerability has been resolved:
tls: separate no-async decryption request handling from async
If we're not doing
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.
Red Hat
kernel: tls: separate no-async decryption request handling from async
vendor_redhat·2025-08-28·CVSS 7.8
CVE-2024-58240 [HIGH] CWE-416 kernel: tls: separate no-async decryption request handling from async
kernel: tls: separate no-async decryption request handling from async
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-triggerab
Microsoft
tls: separate no-async decryption request handling from async
vendor_msrc·2025-08-12·CVSS 7.8
CVE-2024-58240 [HIGH] CWE-416 tls: separate no-async decryption request handling from async
tls: separate no-async decryption request handling from async
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Debian
CVE-2024-58240: linux - In the Linux kernel, the following vulnerability has been resolved: tls: separa...
vendor_debian·2024·CVSS 7.8
CVE-2024-58240 [HIGH] CVE-2024-58240: linux - In the Linux kernel, the following vulnerability has been resolved: tls: separa...
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.
Scope: local
bookworm: resolved (fixed in 6.1.153-1)
bullseye: open
forky: resolved (fixed in 6.7.9-1)
sid: resolved (fixed in 6.7.9-1)
trixie: resolved (fixed in 6.7.9-1)
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/41532b785e9d79636b3815a64ddf6a096647d011https://git.kernel.org/stable/c/48905146d11dbf1ddbb2967319016a83976953f5https://git.kernel.org/stable/c/999115298017a675d8ddf61414fc7a85c89f1186https://git.kernel.org/stable/c/dec5b6e7b211e405d3bcb504562ab21aa7e5a64dhttps://lists.debian.org/debian-lts-announce/2025/10/msg00008.htmlhttps://cert-portal.siemens.com/productcert/html/ssa-032379.html
2025-08-28
Published