CVE-2023-52648 is a now-patched vulnerability in the Linux kernel’s drm/vmwgfx driver. It allowed attackers (or unlucky users) to crash Linux desktops (notably KDE KWin 6. on Wayland) with a Null Pointer Dereference. The issue stemmed from improper management of surface mappings when switching plane states, particularly during cursor operations. If you’re running Linux as a VM guest (for example, on VMware), keep reading — this bug likely affected you.

In non-technical terms: A mistake in cursor handling could crash your virtual Linux desktop.

What Happened?

The problematic driver, vmwgfx, is used for graphics support in VMware virtual machines running Linux. Managing surface memory is tricky — especially with atomic plane state changes (e.g., moving or transforming a cursor).

During some cursor operations, the driver cached mapped surfaces, but forgot to clear a key “mapped” flag after releasing the old graphics surface. As a result, when cleaning up, the system believed a surface was still mapped … when in reality it had gone away. This led to the kernel running off into memory that didn’t belong to it, resulting in an Oops and a desktop crash.

Linux kernel crash logs looked like this

Oops: 000 [#1] PREEMPT SMP PTI
CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.-rc3-vmwgfx #2
...
RIP: 001:vmw_du_cursor_plane_cleanup_fb+x124/x140 [vmwgfx]
Code: ... <48> 8b 78 28 ...
...
Call Trace:
 vmw_du_cursor_plane_cleanup_fb+x124/x140 [vmwgfx]
 drm_atomic_helper_cleanup_planes+x9b/xc
 commit_tail+xd1/x130
 drm_atomic_helper_commit+x11a/x140
...
CR2: 0000000000000028
---[ end trace 000000000000000 ]---

This shows exactly where it broke — in the cursor cleanup function. The kernel tried to access a memory address that didn’t exist because surface was no longer present, but the driver thought it was still mapped.

Here’s a stripped-down version of what went wrong (not the full code)

// State for a "plane" (usually the cursor)
struct vmw_plane_state {
    struct vmw_surface *surface;
    bool surface_mapped;
    ...
};

static void vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane, struct drm_plane_state *old_state) {
    struct vmw_plane_state *vps = to_vmw_plane_state(old_state);

    if (vps->surface_mapped) {
        // Oops: surface might be gone already
        vmw_surface_unmap(vps->surface);
    }
    // Forgetting to reset surface_mapped or check if surface is valid
}

// BAD: surface_mapped stays true even when surface is NULL, causing a crash

The mistake:
surface_mapped flag was still true after the surface was released/unreferenced. The function would try to unmap a non-existent surface.

The Fix

The kernel maintainers fixed this by resetting the surface_mapped flag to false after unreferencing the surface, ensuring future calls would not try to access a freed object.

Official commit:
drm/vmwgfx: Unmap the surface before resetting it on a plane state (commit)

Relevant fixed code

if (vps->surface_mapped) {
    vmw_surface_unmap(vps->surface);
    vps->surface_mapped = false; // <-- THE FIX
}

## Exploit/Impact

This vulnerability can be triggered by normal use (dragging cursor in KDE KWin, for example). While not an “exploit” in the traditional sense (i.e., running remote code), it’s a local Denial-of-Service (DoS) — you can crash your desktop session or potentially the whole VM/kernel.

Move the cursor or perform operations that trigger plane state changes.

3. Watch for a sudden crash; kernel logs/Oops will match above.

Note: Most distributions have patched this by now.

References

- Upstream Linux kernel commit fixing the bug
- Canonical Ubuntu Security Notice USN-6638-1
- Red Hat Bugzilla – Bug 2253464
- KDE KWin 6. release notes (cursor/Wayland support)

Conclusion

CVE-2023-52648 is a classic example of a small “bookkeeping” bug (a forgotten flag) with big consequences. In modern graphics stacks, one wrong flag can bring your desktop or even kernel to a halt. Thanks to quick upstream fixes, a kernel update is all you need.

Action: If you use VMware with a Linux guest, make sure your system is up to date!

*Exclusively written for technical readers who want to understand the real-world impact of a small bug in critical infrastructure. If you want more details or have questions, feel free to ask!*

Timeline

Published on: 05/01/2024 06:15:07 UTC
Last modified on: 09/18/2025 14:19:47 UTC