{"uuid": "4bd953c6-4969-494c-9d32-42c45b794d9c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-26584", "type": "seen", "source": "https://t.me/arpsyndicate/4012", "content": "#ExploitObserverAlert\n\nCVE-2024-26584\n\nDESCRIPTION: Exploit Observer has 1 entries in 1 file formats related to CVE-2024-26584. 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.", "creation_timestamp": "2024-02-22T19:21:06.000000Z"}