CVE-2026-23215
Received Received - Intake
Kernel Pointer Corruption in Linux x86 VMware Hypercall Causes Panic

Publication date: 2026-02-18

Last updated on: 2026-03-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: x86/vmware: Fix hypercall clobbers Fedora QA reported the following panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ... because the QEMU VMware mouse emulation is buggy, and clears the top 32 bits of %rdi that the kernel kept a pointer in. The QEMU vmmouse driver saves and restores the register state in a "uint32_t data[6];" and as a result restores the state with the high bits all cleared. RDI originally contained the value of a valid kernel stack address (0xff5eeb3240003e54). After the vmware hypercall it now contains 0x40003e54, and we get a page fault as a result when it is dereferenced. The proper fix would be in QEMU, but this works around the issue in the kernel to keep old setups working, when old kernels had not happened to keep any state in %rdi over the hypercall. In theory this same issue exists for all the hypercalls in the vmmouse driver; in practice it has only been seen with vmware_hypercall3() and vmware_hypercall4(). For now, just mark RDI/RSI as clobbered for those two calls. This should have a minimal effect on code generation overall as it should be rare for the compiler to want to make RDI/RSI live across hypercalls.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-18
Last Modified
2026-03-18
Generated
2026-05-07
AI Q&A
2026-02-18
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23215
EUVD
EUVD-2026-8017
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.13 (inc) to 6.18.10 (exc)
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.11 (inc) to 6.12.70 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's x86 VMware mouse emulation driver (vmmouse). The issue arises because the QEMU VMware mouse emulation is buggy and clears the top 32 bits of the %rdi register, which the kernel uses to keep a pointer. Specifically, the vmmouse driver saves and restores register state using a 32-bit data array, which causes the high bits of the register to be cleared when restoring state.

As a result, a valid kernel stack address stored in %rdi loses its high bits after a VMware hypercall, leading to an invalid address and causing a page fault when the kernel tries to dereference it. The problem has been observed mainly with vmware_hypercall3() and vmware_hypercall4(). The fix involves marking the RDI and RSI registers as clobbered for these hypercalls to prevent the kernel from relying on their values across the calls.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to panic due to a page fault triggered by an invalid memory address dereference. This happens because the VMware mouse emulation driver incorrectly handles register state, leading to corrupted pointers.

The impact is primarily system instability or crashes when running Linux in virtualized environments using QEMU with VMware mouse emulation. This could disrupt normal operations and potentially cause data loss or service downtime.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

This vulnerability is caused by a bug in the QEMU VMware mouse emulation that clears the top 32 bits of the %rdi register, leading to a kernel panic due to a page fault.

The proper fix is in QEMU, but the kernel workaround marks the RDI/RSI registers as clobbered for the vmware_hypercall3() and vmware_hypercall4() calls to prevent the issue.

Immediate mitigation steps would involve updating the Linux kernel to a version that includes this fix to avoid the page fault and kernel panic.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart