CVE-2025-38187

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The vulnerable code is in the nouveau GSP-RM RPC layer, reached through local GPU device operations and power-management transitions (DRM device open/close driving runtime PM, or system suspend/resume). There is no network or remote-peer input path to `r535_gsp_rpc_push()`.

AC:LAttack complexity, low

The free and the subsequent use are sequential within the same thread, so no race must be won — every large RPC (any FBSR memlist over ~33 MB, which is the normal case on GSP GPUs) deterministically reads freed memory. Reallocation of the freed order-5/6 block by the immediately following `r535_gsp_rpc_get()` is likewise deterministic behaviour of the buddy allocator, and heap grooming from another CPU is fully under attacker control.

PR:LPrivileges required, low

An unprivileged local user with access to the DRM render node can drive nouveau runtime-PM suspend/resume cycles (which invoke `r535_gsp_fini(suspend=true)` → `fbsr->suspend` → the large memlist RPC) simply by opening and closing the device; on typical desktop/laptop systems an active local session can also request system suspend via logind without elevated rights.

UI:NUser interaction, none

No victim action is needed — GPU runtime suspend fires automatically on idle and can be induced by the attacker's own process lifecycle, so the vulnerable path executes without any other user interacting with the system.

S:UScope, unchanged

The use-after-free and its consequences are contained within the kernel's own security authority; the corrupted DMA descriptors are consumed by the GPU within the driver's existing mappings rather than crossing a VM or IOMMU security boundary.

C:HConfidentiality impact, high

Up to hundreds of kilobytes of freed kernel heap are read and transmitted verbatim to the GSP firmware as RPC continuation records, and because those bytes are interpreted as physical page descriptors for the VRAM save/restore DMA, a groomed heap lets an attacker steer GPU DMA reads at arbitrary memory.

I:HIntegrity impact, high

The stale data read from the freed container becomes the PTE array that GSP-RM uses as DMA targets for writing saved VRAM contents, so attacker-controlled reallocation of that buffer yields arbitrary physical-memory writes performed by the GPU; even without grooming the driver corrupts its own freshly allocated container through the overlapping memcpy.

A:HAvailability impact, high

The use-after-free reliably corrupts the FBSR memlist sent to GSP-RM, producing firmware hangs, RPC timeouts, WARN/oops and failed resume that leave the GPU and often the machine unusable, and it trips KASAN/hardened-usercopy style fatal reports.