| Summary: |
VUL-0: CVE-2024-26584: kernel: net: tls: handle backlogging of crypto requests |
| Product: |
[Novell Products] SUSE Security Incidents
|
Reporter: |
SMASH SMASH <smash_bz> |
| Component: |
Incidents | Assignee: |
Michal Kubeček <mkubecek> |
| Status: |
IN_PROGRESS
---
|
QA Contact: |
Security Team bot <security-team> |
| Severity: |
Normal
|
|
|
| Priority: |
P3 - Medium
|
CC: |
gabriele.sonnu, hare, hvdheuvel, jlee, lidong.zhong, meissner, mhocko, mkoutny
|
| Version: |
unspecified | Flags: |
mhocko:
needinfo?
(meissner)
mhocko:
needinfo?
(hare)
|
| Target Milestone: |
--- | |
|
| Hardware: |
Other | |
|
| OS: |
Other | |
|
| URL: |
https://smash.suse.de/issue/394738/
|
| Whiteboard: |
CVSSv3.1:SUSE:CVE-2024-26584:5.5:(AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) |
|
Found By:
|
Security Response Team
|
Services Priority:
|
|
|---|
|
Business Priority:
|
|
Blocker:
|
---
|
|---|
|
Marketing QA Status:
|
---
|
IT Deployment:
|
---
|
|---|
In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-26584 https://www.cve.org/CVERecord?id=CVE-2024-26584 https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3