Vulnerabilidad en Linux (CVE-2026-23215)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> x86/vmware: Solución para las sobrescrituras de hiperllamadas<br /> <br /> Fedora QA informó el siguiente pánico:<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 /> porque la emulación de ratón QEMU VMware tiene errores y borra los 32 bits superiores de %rdi donde el kernel mantenía un puntero.<br /> <br /> El controlador QEMU vmmouse guarda y restaura el estado del registro en un &amp;#39;uint32_t data[6];&amp;#39; y, como resultado, restaura el estado con todos los bits altos borrados.<br /> <br /> RDI originalmente contenía el valor de una dirección de pila de kernel válida (0xff5eeb3240003e54). Después de la hiperllamada de vmware, ahora contiene 0x40003e54, y obtenemos un fallo de página como resultado cuando es desreferenciado.<br /> <br /> La solución adecuada estaría en QEMU, pero esto evita el problema en el kernel para mantener las configuraciones antiguas funcionando, cuando los kernels antiguos no habían guardado ningún estado en %rdi durante la hiperllamada.<br /> <br /> En teoría, este mismo problema existe para todas las hiperllamadas en el controlador vmmouse; en la práctica, solo se ha visto con vmware_hypercall3() y vmware_hypercall4(). Por ahora, simplemente marca RDI/RSI como sobrescritos para esas dos llamadas. Esto debería tener un efecto mínimo en la generación de código en general, ya que debería ser raro que el compilador quiera mantener RDI/RSI activos a través de hiperllamadas.