Skip to content

memory management dangling pointer LPE (CVE-2025-6349)

A use-after-free in the Arm Mali GPU kernel driver (Valhall / 5th Gen GPU): improper GPU memory-processing operations leave a dangling pointer to a freed allocation, giving a local non-privileged process access to freed kernel memory — the seed for local privilege escalation.

Mechanism

Why it works

A dangling pointer is a reference that outlives the object it points to. When a kernel allocation is freed but a pointer to it is not cleared (or a second code path keeps using it), the slab/page allocator is free to recycle that memory for an unrelated object. Any subsequent dereference of the stale pointer then reads or writes whatever now occupies the slot — a classic use-after-free (UAF, CWE-416).

GPU drivers are an especially rich source of these bugs because they manage a second memory namespace on behalf of userland: GPU virtual address spaces, memory "regions"/handles, and the page tables that back them. The lifecycle of a GPU memory object is driven by ioctls (allocate region, map, JIT-allocate, free, etc.). If the reference counting or the ordering between "tear down the GPU mapping" and "free the backing pages" is wrong, an unprivileged process can drive the driver into a state where a freed object is still reachable through a GPU VA or an in-kernel handle.

Per the NVD/vendor description, CVE-2025-6349 is exactly this shape:

"Use After Free vulnerability in Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user process to perform improper GPU memory processing operations to gain access to already freed memory."

The companion bug CVE-2025-8045 carries an almost identical description ("improper GPU processing operations"). Both are in the Mali kbase kernel driver, and both fall in the r53p0 → r54p1 version range (fixed in r54p2 / r55p0).

Why it matters for LPE: the Mali driver runs in ring 0. Once an attacker controls the contents that land in a freed GPU-memory object, they can reclaim that slot with an attacker-shaped kernel object (cross-cache / heap spray) and convert the UAF into an arbitrary read/write primitive — the standard route to overwriting credentials or page-table entries and escalating to root.

Scope note

Despite the "memory management" framing in this entry's title, CVE-2025-6349 is not a bug in Linux core mm/. It lives in Arm's out-of-tree Mali GPU kernel driver (the kbase driver, vendor path drivers/gpu/arm/...). The "dangling pointer" is a GPU memory-object pointer inside that driver, not a generic kernel VMA/page bug. Arm publishes these under its own product-security advisory rather than the kernel.org CVE stream.

Walkthrough

Authorized testing only

Run only against devices/kernels you own or are authorized to test. Mali driver internals (struct layouts, ioctl numbers, region flags) differ per rXXpY release and per SoC. The steps below describe the class of technique; they are not a turnkey exploit and intentionally omit a weaponized chain.

1. Confirm the driver and version. The Mali kernel driver exposes a device node and reports its version via an ioctl/version handshake.

$ ls -l /dev/mali0
crw-rw-rw- 1 system graphics 234, 0 /dev/mali0

# Driver version is surfaced in dmesg / sysfs on many vendor kernels:
$ dmesg | grep -i 'mali\|kbase'
mali ... : Kernel DDK version r54p0 ...

A reported version in the r53p0–r54p1 band is in range for CVE-2025-6349 / CVE-2025-8045.

2. Open the device and run the version setup handshake. Userland talks to kbase through KBASE_IOCTL_VERSION_CHECK and KBASE_IOCTL_SET_FLAGS before any memory ioctl is accepted.

int fd = open("/dev/mali0", O_RDWR);
/* KBASE_IOCTL_VERSION_CHECK then KBASE_IOCTL_SET_FLAGS — exact struct
   layouts are version-specific; consult the matching kbase headers. */

3. Drive the vulnerable memory-processing path. The bug is reached by issuing the specific sequence of GPU memory operations the advisory calls "improper GPU memory processing." Conceptually:

  • allocate one or more GPU memory regions / handles;
  • start an operation that takes a reference (or a raw pointer) to a region's backing object;
  • free / shrink / re-map that region so its backing memory is released while the in-flight operation still holds the stale pointer.

The result is a freed allocation that the driver continues to treat as live.

4. Reclaim the freed slot. Spray replacement objects of the matching size so a controlled kernel object lands in the freed slot. For UAFs on the slab, this is the usual heap-spray / cross-cache step; for page-granular GPU allocations it is a page-level reclaim.

5. Promote to arbitrary R/W and escalate. With a controlled object in the freed slot, the stale GPU pointer reads/writes attacker-shaped data. From an arbitrary write, the standard finishers apply: overwrite a cred struct, flip a page-table entry, or hijack a function pointer to run a token-stealing payload.

Expected observable during PoC bring-up: a KASAN-instrumented test kernel prints
"BUG: KASAN: use-after-free" / "slab-use-after-free" with the kbase free/alloc
stacks when the stale pointer is dereferenced — the ground-truth signal that the
UAF triggered before any reclaim is wired up.

Detection

  • KASAN on a test kernel is the definitive trigger oracle: it reports use-after-free with both the allocation and the free stack inside the Mali driver.
  • On production devices, watch for unexpected mali/kbase oopses, GPU faults, or kernel panics correlated with unusual ioctl sequences against /dev/mali0.
  • EDR/MDM can flag the bug class indirectly: an unprivileged app repeatedly opening /dev/mali0 and issuing dense allocate/free/map ioctl bursts is anomalous for most apps.

Mitigation

  • Patch. Update the Mali GPU kernel driver to r54p2 / r55p0 or later (the fixed releases per Arm's advisory), typically delivered through the device vendor's security maintenance release.
  • Keep CONFIG_SLAB_FREELIST_HARDENED / freelist randomization and (where available) per-object UAF mitigations enabled to raise the cost of reclaim.
  • Restrict /dev/mali0 permissions where the platform's sandbox model allows it, to shrink the set of processes that can reach the driver.

References