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.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel stability flaw in VMware-compatible mouse hypercall handling. In affected x86 virtualized setups, a buggy VMware mouse emulation path can corrupt saved register values and cause a kernel page fault and panic. The public sources describe a crash condition, not confirmed data theft or active exploitation.
Executive priority
Treat this as a targeted kernel reliability issue for virtualized Linux fleets, not a confirmed breach signal. Patch through normal kernel maintenance, accelerating for desktop, QA, or virtualization images where VMware-compatible mouse emulation is used.
Technical view
The kernel fix marks RDI/RSI as clobbered for vmware_hypercall3() and vmware_hypercall4(). QEMU vmmouse emulation saved register state in 32-bit storage, clearing upper bits of 64-bit pointer registers. When the kernel later dereferenced the truncated pointer, it faulted in kernel mode.
Likely exposure
Exposure appears limited to affected Linux kernel versions on x86 systems using VMware/vmmouse hypercall paths, including QEMU VMware mouse emulation. The bundle does not define exact distributions, package names, or deployment prevalence.
Exploitation context
The sources report a Fedora QA crash and say the underlying issue is buggy QEMU VMware mouse emulation. KEV is false, and the bundle contains no evidence of active exploitation, public weaponization, privilege escalation, or remote attack.
Researcher notes
The record lacks CVSS, CWE, and detailed affected-version range semantics. Analysis should focus on kernel commit inclusion, distro backports, and whether the vmmouse path is reachable in local virtualization configurations. Do not infer exploitability beyond the documented panic.
Mitigation direction
Apply Linux kernel vendor updates containing the referenced stable fixes.
Prioritize x86 virtualized systems using VMware-compatible mouse or vmmouse paths.
Check distribution advisories for affected package versions and backport status.
If updates are unavailable, follow vendor guidance for temporary risk reduction.
Validation and detection
Inventory Linux kernel versions against vendor advisories for CVE-2026-23215.
Verify installed kernels include the referenced stable commits or distro backports.
Review crash logs for vmmouse_report_events or vmware_hypercall page faults.
Confirm whether affected systems expose VMware-compatible mouse emulation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23215 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Feb 18, 2026, 14:21 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.