CVE-2024-35951

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 path is reached only through local ioctls (PANFROST_IOCTL_CREATE_BO with PANFROST_BO_HEAP, then PANFROST_IOCTL_SUBMIT) on the DRM render node /dev/dri/renderD128. No network or adjacent-network exposure exists.

AC:LAttack complexity, low

The error path requires an allocation failure, and the BO's shmem mapping is deliberately created with __GFP_RETRY_MAYFAIL|GFP_HIGHUSER so it returns -ENOMEM instead of OOM-killing; the attacker fully controls memory pressure and GPU IOVA exhaustion (failing dma_map_sgtable) and can re-trigger the fault in a loop with no race to win.

PR:LPrivileges required, low

Both required ioctls are DRM_RENDER_ALLOW, so any local unprivileged user with render-node access — the default for logged-in desktop users, and for every application on Android/ChromeOS devices using Mali GPUs — can reach the code with no capabilities.

UI:NUser interaction, none

The attacker performs every step itself: creating the heap BO, submitting the job that faults, and generating the memory pressure. No victim action is involved.

S:UScope, unchanged

The buggy driver and the corrupted memory both reside within the kernel's security authority; this is standard kernel memory corruption rather than a VM or hypervisor boundary escape.

C:HConfidentiality impact, high

Pages that remain mapped read/write in the GPU address space lose their driver reference and are made evictable, so once reclaimed and reused the attacker's GPU shaders can read arbitrary recycled kernel and userspace memory through the stale mapping.

I:HIntegrity impact, high

The stale GPU mappings carry IOMMU_WRITE, giving the attacker an arbitrary write primitive into reclaimed memory, and the leaked/overwritten sg tables plus re-mapping over live PTEs further corrupt the GPU page tables and page refcounts.

A:HAvailability impact, high

The unbalanced put_pages corrupts page reference counts and permanently leaks sg tables and DMA/IOVA mappings, while the failed fault disables the GPU address space and kills all jobs on it; repeated triggering yields memory exhaustion and kernel oopses/panics.