// For flags

CVE-2024-26831

net/handshake: Fix handshake_req_destroy_test1

Severity Score

7.8
*CVSS v3

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

In the Linux kernel, the following vulnerability has been resolved: net/handshake: Fix handshake_req_destroy_test1 Recently, handshake_req_destroy_test1 started failing: Expected handshake_req_destroy_test == req, but handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40
not ok 11 req_destroy works This is because "sock_release(sock)" was replaced with "fput(filp)"
to address a memory leak. Note that sock_release() is synchronous
but fput() usually delays the final close and clean-up. The delay is not consequential in the other cases that were changed
but handshake_req_destroy_test1 is testing that handshake_req_cancel()
followed by closing the file actually does call the ->hp_destroy
method. Thus the PTR_EQ test at the end has to be sure that the
final close is complete before it checks the pointer. We cannot use a completion here because if ->hp_destroy is never
called (ie, there is an API bug) then the test will hang. Reported by: Guenter Roeck <linux@roeck-us.net>

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/handshake: Fix handshake_req_destroy_test1 Recientemente, handshake_req_destroy_test1 comenzó a fallar: Se esperaba handshake_req_destroy_test == req, pero handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40 no ok 11 req_destroy funciona Esto se debe a que "sock_release( calcetín)" fue reemplazado por "fput(filp)" para solucionar una pérdida de memoria. Tenga en cuenta que sock_release() es sincrónico pero fput() normalmente retrasa el cierre y la limpieza finales. El retraso no tiene consecuencias en los otros casos que se cambiaron, pero handshake_req_destroy_test1 está probando que handshake_req_cancel() seguido del cierre del archivo realmente llama al método -&gt;hp_destroy. Por lo tanto, la prueba PTR_EQ al final debe asegurarse de que el cierre final esté completo antes de verificar el puntero. No podemos usar una finalización aquí porque si nunca se llama a -&gt;hp_destroy (es decir, hay un error de API), la prueba se bloqueará. Reportado por: Guenter Roeck

In the Linux kernel, the following vulnerability has been resolved: net/handshake: Fix handshake_req_destroy_test1 Recently, handshake_req_destroy_test1 started failing: Expected handshake_req_destroy_test == req, but handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40 not ok 11 req_destroy works This is because "sock_release(sock)" was replaced with "fput(filp)" to address a memory leak. Note that sock_release() is synchronous but fput() usually delays the final close and clean-up. The delay is not consequential in the other cases that were changed but handshake_req_destroy_test1 is testing that handshake_req_cancel() followed by closing the file actually does call the ->hp_destroy method. Thus the PTR_EQ test at the end has to be sure that the final close is complete before it checks the pointer. We cannot use a completion here because if ->hp_destroy is never called (ie, there is an API bug) then the test will hang. Reported by: Guenter Roeck <linux@roeck-us.net>

It was discovered that the ATA over Ethernet driver in the Linux kernel contained a race condition, leading to a use-after-free vulnerability. An attacker could use this to cause a denial of service or possibly execute arbitrary code. It was discovered that the HugeTLB file system component of the Linux Kernel contained a NULL pointer dereference vulnerability. A privileged attacker could possibly use this to to cause a denial of service.

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High
Attack Vector
Local
Attack Complexity
Medium
Authentication
None
Confidentiality
Complete
Integrity
Complete
Availability
Complete
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-02-19 CVE Reserved
  • 2024-04-17 CVE Published
  • 2024-12-19 CVE Updated
  • 2025-03-19 EPSS Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.6.18
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.6.18"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.7.6
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.7.6"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.8"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
6.5.6
Search vendor "Linux" for product "Linux Kernel" and version "6.5.6"
en
Affected