// For flags

CVE-2024-26912

drm/nouveau: fix several DMA buffer leaks

Severity Score

5.5
*CVSS v3.1

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: drm/nouveau: fix several DMA buffer leaks Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of
these buffers are never dealloced. Some of them can be deallocated
right after GSP-RM is initialized, but the rest need to stay until the
driver unloads. Also futher bullet-proof these objects by poisoning the buffer and
clearing the nvkm_gsp_mem object when it is deallocated. Poisoning
the buffer should trigger an error (or crash) from GSP-RM if it tries
to access the buffer after we've deallocated it, because we were wrong
about when it is safe to deallocate. Finally, change the mem->size field to a size_t because that's the same
type that dma_alloc_coherent expects.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: corrige varias fugas del búfer DMA Nouveau administra los buffers DMA GSP-RM con objetos nvkm_gsp_mem. Varios de estos búferes nunca se desasignan. Algunos de ellos se pueden desasignar inmediatamente después de que se inicializa GSP-RM, pero el resto debe permanecer hasta que se descargue el controlador. También proteja aún más estos objetos envenenando el búfer y limpiando el objeto nvkm_gsp_mem cuando se desasigna. El envenenamiento del búfer debería provocar un error (o bloqueo) de GSP-RM si intenta acceder al búfer después de haberlo desasignado, porque nos equivocamos acerca de cuándo es seguro desasignarlo. Finalmente, cambie el campo mem->size a size_t porque es el mismo tipo que espera dma_alloc_coherent.

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix several DMA buffer leaks Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of these buffers are never dealloced. Some of them can be deallocated right after GSP-RM is initialized, but the rest need to stay until the driver unloads. Also futher bullet-proof these objects by poisoning the buffer and clearing the nvkm_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries to access the buffer after we've deallocated it, because we were wrong about when it is safe to deallocate. Finally, change the mem->size field to a size_t because that's the same type that dma_alloc_coherent expects.

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
Attack Vector
Local
Attack Complexity
Low
Authentication
Single
Confidentiality
None
Integrity
None
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-30 EPSS Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
  • CWE-401: Missing Release of Memory after Effective Lifetime
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.7 < 6.7.6
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.7.6"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.7 < 6.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.8"
en
Affected