https://bugzilla.kernel.org/show_bug.cgi?id=220339
Bug ID: 220339
Summary: Use-After-Free in vmw_surface_unref_ioctl() in vmwgfx
DRM Driver via Stale Surface Handle Dereference
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Video(DRI - non Intel)
Assignee: drivers_video-...@kernel-bugs.osdl.org
Reporter: lewischarlie2...@gmail.com
Regression: No
Vulnerability Summary
A local use-after-free (UAF) vulnerability exists in the VMware graphics driver
(vmwgfx) within the Linux kernel. Specifically, the bug lies in the
vmw_surface_unref_ioctl() handler in drivers/gpu/drm/vmwgfx/vmwgfx_surface.c.
This function may invoke a function pointer on a freed surface object, leading
to a NULL dereference or controlled RIP hijack depending on heap state. Under
controlled conditions, this can result in full local privilege escalation
(LPE).
Affected Component
Subsystem: drivers/gpu/drm/vmwgfx/
File: vmwgfx_surface.c
Function: vmw_surface_unref_ioctl()
Kernel Version: Confirmed on 6.11.2-amd64 (Kali Linux)
Upstream Impact: Likely still present upstream if no recent logic changes were
made in the unref path
Vulnerability Details
The vmw_surface_unref_ioctl() function is responsible for unreferencing surface
objects allocated by vmw_surface_define_ioctl(). Internally, each surface is
tracked via struct vmw_surface, which embeds a struct vmw_resource. This
resource structure contains a function pointer table (res.func) used for
cleanup operations.
If a surface is freed (e.g., via multiple unref calls or race conditions), but
the object is still referenced and later used, the kernel may dereference a
dangling function pointer via:
surface->res.func->destroy(&surface->res, file_priv);
This results in:
NULL pointer dereference (if the function pointer is cleared)
Controlled RIP hijack (if the heap is sprayed with a fake struct vmw_resource
pointing into userland)
Local Privilege Escalation
Exploit Conditions
Access Vector: Local
Privileges Required: Access to /dev/dri/card0 (being in the video group which
is unlikely for alot of users in systems but still possible)
Exploitation Primitives:
Predictable heap layout via object spraying
Memory mapped fake surface object (e.g., at 0xdead000)
Controlled overwrite of res.func or related pointers
Proof-of-Concept Summary
// PoC behavior:
1. mmap(0xdead000, ...)
2. Write fake ROP chain and fake function pointer table
3. Spray surface objects to groom heap
4. Trigger unref via ioctl()
5. RIP hijack or kernel crash
Kernel Output (dmesg):
[ 4111.830421] uaf[4350]: segfault at 0 ip 0000000000000000 sp 00007ffedac84fc0
error 14 in uaf[400000+1000]
[ 4111.830485] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
Root Cause
// vmw_surface_unref_ioctl() pseudocode:
surface = vmw_surface_lookup(dev_priv, sid); // May return freed object
...
surface->res.func->destroy(&surface->res, file_priv); // Dangling pointer
deref
If surface has been freed and memory is reallocated or attacker-controlled,
this dereference leads to a segfault or arbitrary code execution in kernel
mode.
Impact
Denial of Service (DoS): via NULL pointer dereference
Privilege Escalation (LPE): via RIP hijack and controlled ROP chain execution
in kernel
Recommended Fix
Validate surface->res.func before use
Implement reference count protection on vmw_surface
Apply lock or RCU logic to guard against stale pointer dereference
Adittional Info:
Im waiting on the Linux Kernel to finish Building with Kasan to get the Kasan
Report. Once completed I will add as an attachment / comment.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
