CVE-2026-23215

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/vmware: Fix hypercall clobbers<br /> <br /> Fedora QA reported the following panic:<br /> <br /> BUG: unable to handle page fault for address: 0000000040003e54<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025<br /> RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90<br /> ..<br /> Call Trace:<br /> vmmouse_report_events+0x13e/0x1b0<br /> psmouse_handle_byte+0x15/0x60<br /> ps2_interrupt+0x8a/0xd0<br /> ...<br /> <br /> because the QEMU VMware mouse emulation is buggy, and clears the top 32<br /> bits of %rdi that the kernel kept a pointer in.<br /> <br /> The QEMU vmmouse driver saves and restores the register state in a<br /> "uint32_t data[6];" and as a result restores the state with the high<br /> bits all cleared.<br /> <br /> RDI originally contained the value of a valid kernel stack address<br /> (0xff5eeb3240003e54). After the vmware hypercall it now contains<br /> 0x40003e54, and we get a page fault as a result when it is dereferenced.<br /> <br /> The proper fix would be in QEMU, but this works around the issue in the<br /> kernel to keep old setups working, when old kernels had not happened to<br /> keep any state in %rdi over the hypercall.<br /> <br /> In theory this same issue exists for all the hypercalls in the vmmouse<br /> driver; in practice it has only been seen with vmware_hypercall3() and<br /> vmware_hypercall4(). For now, just mark RDI/RSI as clobbered for those<br /> two calls. This should have a minimal effect on code generation overall<br /> as it should be rare for the compiler to want to make RDI/RSI live<br /> across hypercalls.