Bug 2265519 (CVE-2024-26584)
| Summary: | CVE-2024-26584 kernel: tls: handle backlogging of crypto requests | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Patrick Del Bello <pdelbell> |
| Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
| Status: | NEW --- | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | acaringi, allarkin, aquini, bhu, chwhite, cye, cyin, dbohanno, debarbos, dfreiber, drow, dvlasenk, esandeen, ezulian, hkrzesin, jarod, jburrell, jdenham, jfaracco, jforbes, jlelli, joe.lawrence, jshortt, jstancek, jwyatt, kcarcia, kyoshida, ldoskova, lgoncalv, lzampier, mleitner, mmilgram, mstowell, nmurray, ptalbert, rparrazo, rrobaina, rvrbovsk, rysulliv, scweaver, sukulkar, tglozar, tyberry, vkumar, wcosta, williams, wmealing, ycote, ykopkova, zhijwang |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel 6.8-rc5 | Doc Type: | If docs needed, set a value |
| Doc Text: |
A flaw was found in the tls subsystem of the Linux kernel. When setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on requests to the crypto API, crypto_aead_encrypt and crypto_aead_decrypt functions can return -EBUSY instead of -EINPROGRESS in valid situations. This issue could lead to undefined behavior and a denial of service condition.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2265534 | ||
| Bug Blocks: | 2265516 | ||
Kernel security advisory: https://lore.kernel.org/linux-cve-announce/2024022148-showpiece-yanking-107c@gregkh/T/#u Upstream fix: https://github.com/torvalds/linux/commit/859054147318 Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2265534] This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Extended Update Support Via RHSA-2024:1882 https://access.redhat.com/errata/RHSA-2024:1882 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Extended Update Support Via RHSA-2024:1881 https://access.redhat.com/errata/RHSA-2024:1881 This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:2394 https://access.redhat.com/errata/RHSA-2024:2394 The result of automatic check (that is developed by Alexander Larkin) for this CVE-2024-26584 is: CHECK Maybe valid. Check manually. with impact LOW (that is an approximation based on flags REMOTE INIT LOG ; these flags parsed automatically based on patch data). Such automatic check happens only for Low/Moderates (and only when not from reporter, but parsing already existing CVE). Highs always checked manually (I check it myself and then we check it again in Remediation team). In rare cases some of the Moderates could be increased to High later. This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:4211 https://access.redhat.com/errata/RHSA-2024:4211 This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:4352 https://access.redhat.com/errata/RHSA-2024:4352 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Via RHSA-2024:4447 https://access.redhat.com/errata/RHSA-2024:4447 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:5255 https://access.redhat.com/errata/RHSA-2024:5255 |
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.