SecBoard
Zurück zur CVE-Übersicht

CVE-2024-26584

CRITICAL(9.8)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Risk Signal Score25/100 — MITTEL
  • CVSS 9.8 — Kritisch

EPSS-Score

0.7%

Exploit-Wahrscheinlichkeit (30 Tage)

CVSS Score

9.8

Technische Schwere

SecBoard-Einordnung

CVE-2024-26584 betrifft eine Schwachstelle im Linux-Kernel, genauer im TLS-Subsystem bei der Handhabung von Krypto-Anfragen. Diese Schwachstelle kann dazu führen, dass asynchrone Callbacks doppelt aufgerufen werden, was potenziell zu unerwartetem Verhalten oder Fehlern führen kann. Die genaue Auswirkung auf die Vertraulichkeit, Integrität oder Verfügbarkeit ist nicht detailliert beschrieben, aber die Natur der Schwachstelle deutet auf Stabilitätsprobleme hin. Die Schwachstelle wird mit einem CVSS-Score von 9.8 als kritisch eingestuft, was auf ein sehr hohes Risiko hindeutet. Trotz der hohen Kritikalität liegt die Exploit-Wahrscheinlichkeit gemäß bei nur 1%, und die Schwachstelle ist derzeit nicht im KEV-Katalog der aktiv ausgenutzten Schwachstellen gelistet. Dies deutet darauf hin, dass sie aktuell nicht aktiv in freier Wildbahn ausgenutzt wird, aber das Potenzial für schwerwiegende Auswirkungen besteht. Security-Teams sollten die Verfügbarkeit von Patches für ihre Linux-Systeme genau überwachen und diese umgehend einspielen, sobald sie verfügbar sind. Obwohl die aktive Ausnutzung derzeit gering ist, erfordert die hohe CVSS-Bewertung eine schnelle Reaktion, um potenzielle Risiken zu minimieren. Eine Priorisierung des Patch-Managements für betroffene Linux-Kernel-Installationen ist dringend empfohlen.

KI-gestützte Einordnung auf Basis der NVD-Daten.

Beschreibung

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.

Referenzen