CVE-2026-23215

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.