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.
Metrics
Affected Vendors & Products
References
History
Sat, 30 Aug 2025 00:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Weaknesses | CWE-416 | |
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Thu, 28 Aug 2025 21:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Linux
Linux linux Kernel |
|
Vendors & Products |
Linux
Linux linux Kernel |
Thu, 28 Aug 2025 14:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
|
Thu, 28 Aug 2025 12:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | 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. | |
Title | tls: separate no-async decryption request handling from async | |
References |
|

Status: PUBLISHED
Assigner: Linux
Published: 2025-08-28T09:40:33.466Z
Updated: 2025-08-28T14:42:46.015Z
Reserved: 2025-04-16T07:19:43.804Z
Link: CVE-2024-58240

No data.

Status : Awaiting Analysis
Published: 2025-08-28T10:15:31.780
Modified: 2025-08-29T16:24:09.860
Link: CVE-2024-58240
