gsd-2024-26584
Vulnerability from gsd
Modified
2024-02-20 06:02
Details
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.
Aliases
{ "gsd": { "metadata": { "exploitCode": "unknown", "remediation": "unknown", "reportConfidence": "confirmed", "type": "vulnerability" }, "osvSchema": { "aliases": [ "CVE-2024-26584" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: handle backlogging of crypto requests\n\nSince we\u0027re setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our\nrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return\n -EBUSY instead of -EINPROGRESS in valid situations. For example, when\nthe cryptd queue for AESNI is full (easy to trigger with an\nartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued\nto the backlog but still processed. In that case, the async callback\nwill also be called twice: first with err == -EINPROGRESS, which it\nseems we can just ignore, then with err == 0.\n\nCompared to Sabrina\u0027s original patch this version uses the new\ntls_*crypt_async_wait() helpers and converts the EBUSY to\nEINPROGRESS to avoid having to modify all the error handling\npaths. The handling is identical.", "id": "GSD-2024-26584", "modified": "2024-02-20T06:02:29.096869Z", "schema_version": "1.4.0" } }, "namespaces": { "cve.org": { "CVE_data_meta": { "ASSIGNER": "cve@kernel.org", "ID": "CVE-2024-26584", "STATE": "PUBLIC" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "Linux", "version": { "version_data": [ { "version_affected": "\u003c", "version_name": "a54667f6728c", "version_value": "cd1bbca03f3c" }, { "version_value": "not down converted", "x_cve_json_5_version_data": { "defaultStatus": "affected", "versions": [ { "status": "affected", "version": "4.16" }, { "lessThan": "4.16", "status": "unaffected", "version": "0", "versionType": "custom" }, { "lessThanOrEqual": "6.1.*", "status": "unaffected", "version": "6.1.84", "versionType": "custom" }, { "lessThanOrEqual": "6.6.*", "status": "unaffected", "version": "6.6.18", "versionType": "custom" }, { "lessThanOrEqual": "6.7.*", "status": "unaffected", "version": "6.7.6", "versionType": "custom" }, { "lessThanOrEqual": "*", "status": "unaffected", "version": "6.8", "versionType": "original_commit_for_fix" } ] } } ] } } ] }, "vendor_name": "Linux" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: handle backlogging of crypto requests\n\nSince we\u0027re setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our\nrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return\n -EBUSY instead of -EINPROGRESS in valid situations. For example, when\nthe cryptd queue for AESNI is full (easy to trigger with an\nartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued\nto the backlog but still processed. In that case, the async callback\nwill also be called twice: first with err == -EINPROGRESS, which it\nseems we can just ignore, then with err == 0.\n\nCompared to Sabrina\u0027s original patch this version uses the new\ntls_*crypt_async_wait() helpers and converts the EBUSY to\nEINPROGRESS to avoid having to modify all the error handling\npaths. The handling is identical." } ] }, "generator": { "engine": "bippy-5f0117140d9a" }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "n/a" } ] } ] }, "references": { "reference_data": [ { "name": "https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72" }, { "name": "https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754" }, { "name": "https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694" }, { "name": "https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3" } ] } }, "nvd.nist.gov": { "cve": { "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: handle backlogging of crypto requests\n\nSince we\u0027re setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our\nrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return\n -EBUSY instead of -EINPROGRESS in valid situations. For example, when\nthe cryptd queue for AESNI is full (easy to trigger with an\nartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued\nto the backlog but still processed. In that case, the async callback\nwill also be called twice: first with err == -EINPROGRESS, which it\nseems we can just ignore, then with err == 0.\n\nCompared to Sabrina\u0027s original patch this version uses the new\ntls_*crypt_async_wait() helpers and converts the EBUSY to\nEINPROGRESS to avoid having to modify all the error handling\npaths. The handling is identical." }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tls: manejar el retraso de solicitudes criptogr\u00e1ficas Dado que estamos configurando el indicador CRYPTO_TFM_REQ_MAY_BACKLOG en nuestras solicitudes a la API criptogr\u00e1fica, crypto_aead_{encrypt,decrypt} puede devolver -EBUSY en lugar de - EINPROGRESS en situaciones v\u00e1lidas. Por ejemplo, cuando la cola cryptd para AESNI est\u00e1 llena (f\u00e1cil de activar con un cryptd.cryptd_max_cpu_qlen artificialmente bajo), las solicitudes se pondr\u00e1n en cola en el trabajo pendiente, pero a\u00fan as\u00ed se procesar\u00e1n. En ese caso, la devoluci\u00f3n de llamada as\u00edncrona tambi\u00e9n se llamar\u00e1 dos veces: primero con err == -EINPROGRESS, que parece que podemos ignorar, luego con err == 0. En comparaci\u00f3n con el parche original de Sabrina, esta versi\u00f3n usa el nuevo tls_*crypt_async_wait( ) ayuda y convierte EBUSY a EINPROGRESS para evitar tener que modificar todas las rutas de manejo de errores. El manejo es id\u00e9ntico." } ], "id": "CVE-2024-26584", "lastModified": "2024-04-03T14:15:15.613", "metrics": {}, "published": "2024-02-21T15:15:09.420", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" } } } }
Loading...
Loading...
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.