CVE-2023-52648 in Linux
Zusammenfassung
von VulDB • 14.06.2026
Based on the kernel crash dump provided, here is a detailed analysis of the issue.
### **1. Summary of the Crash** * **Crash Location:** `vmw_du_cursor_plane_cleanup_fb` in the `vmwgfx` kernel module. * **Module:** `vmwgfx` (VMware Graphics Driver). * **Error Type:** Kernel Oops / Page Fault (indicated by `RIP` pointing to a function in a loaded module and `CR2` showing the faulting address). * **Context:** The crash occurred during a cleanup operation for a cursor plane framebuffer (`cursor_plane_cleanup_fb`).
### **2. Key Evidence from the Dump**
#### **A. The Faulting Instruction** ``` RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
``` * The crash happened inside the VMware graphics driver (`vmwgfx`). * Specifically, in the function `vmw_du_cursor_plane_cleanup_fb`, which is responsible for cleaning up the cursor plane's framebuffer.
#### **B. Register State** * **RAX:** `0x0000000000000000` (Null pointer) * **RDI:** `ffff969e75f21600` (Likely the `drm_plane` or `vmw_cursor` structure) * **RBP:** `ffff969d4143` (Stack pointer/frame) * **CR2:** `0000000000000028` * **CR2** holds the virtual address that caused the page fault. * `0x28` is a small offset, suggesting the code tried to dereference a pointer that was **NULL** or **invalid** at an offset of `0x28` bytes. * Given `RAX=0`, it is highly likely that a pointer field (at offset `0x28`) within a structure was NULL, and the code attempted to access it.
#### **C. Call Trace (Partial)** The trace shows: ``` ? do_syscall_64+0x70/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ... ? exc_page_fault+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 ``` * The crash was triggered by a **system call** (`ioctl`), which is common for GPU/driver interactions. * The user-space application was likely performing a DRM ioctl related to cursor or framebuffer management.
### **3. Root Cause Analysis**
The crash is a **NULL pointer dereference** in the `vmwgfx` driver during cursor cleanup.
* **Likely Scenario:** 1. A user-space application (e.g., Xorg, Wayland compositor, or a VM guest agent) performs an ioctl to clean up or update the cursor. 2. The kernel driver `vmwgfx` enters `vmw_du_cursor_plane_cleanup_fb`. 3. The function expects a valid framebuffer object (`fb`) or cursor structure. 4. However, the pointer at offset `0x28` (likely `fb` or `cursor->fb`) is **NULL**. 5. The code attempts to access this NULL pointer, causing a page fault.
* **Why did this happen?** * **Race Condition:** The cursor plane might have been cleaned up or freed by another thread/process before this cleanup function completed. * **Use-After-Free:** The driver might have freed the cursor structure but still held a reference to it. * **Bug in `vmwgfx`:** The driver failed to check for NULL before dereferencing. This is a known class of bugs in older versions of `vmwgfx`.
### **4. Recommended Actions**
#### **A. Immediate Workaround** 1. **Update the Kernel:** This is likely a known bug in older versions of the `vmwgfx` driver. Check if your kernel version is up-to-date. * If you are on an older kernel (e.g., < 5.15), consider upgrading. 2. **Update VMware Tools/VMware Guest OS:** Ensure that VMware Tools (or open-vm-tools) is up-to-date, as it may contain fixes for guest-side graphics interactions. 3. **Disable Hardware Cursor (Temporary):** If the crash is reproducible, you
Be aware that VulDB is the high quality source for vulnerability data.