CVE-2026-23215 (GCVE-0-2026-23215)
Vulnerability from cvelistv5
Published
2026-02-18 14:21
Modified
2026-02-20 11:31
Severity ?
Summary
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.
References
Impacted products
Vendor Product Version
Linux Linux Version: 34bf25e820ae1ab38f9cd88834843ba76678a2fd
Version: 34bf25e820ae1ab38f9cd88834843ba76678a2fd
Version: 34bf25e820ae1ab38f9cd88834843ba76678a2fd
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/include/asm/vmware.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "2f467a92df61eb516a4ec36ee16234dd4e5ccf00",
              "status": "affected",
              "version": "34bf25e820ae1ab38f9cd88834843ba76678a2fd",
              "versionType": "git"
            },
            {
              "lessThan": "feb603a69f830acb58f78d604f0c29e63cd38f87",
              "status": "affected",
              "version": "34bf25e820ae1ab38f9cd88834843ba76678a2fd",
              "versionType": "git"
            },
            {
              "lessThan": "2687c848e57820651b9f69d30c4710f4219f7dbf",
              "status": "affected",
              "version": "34bf25e820ae1ab38f9cd88834843ba76678a2fd",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/include/asm/vmware.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.11"
            },
            {
              "lessThan": "6.11",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.70",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.19",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.70",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.10",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.19",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/vmware: Fix hypercall clobbers\n\nFedora QA reported the following panic:\n\n  BUG: unable to handle page fault for address: 0000000040003e54\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0002) - not-present page\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025\n  RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90\n  ..\n  Call Trace:\n   vmmouse_report_events+0x13e/0x1b0\n   psmouse_handle_byte+0x15/0x60\n   ps2_interrupt+0x8a/0xd0\n   ...\n\nbecause the QEMU VMware mouse emulation is buggy, and clears the top 32\nbits of %rdi that the kernel kept a pointer in.\n\nThe QEMU vmmouse driver saves and restores the register state in a\n\"uint32_t data[6];\" and as a result restores the state with the high\nbits all cleared.\n\nRDI originally contained the value of a valid kernel stack address\n(0xff5eeb3240003e54).  After the vmware hypercall it now contains\n0x40003e54, and we get a page fault as a result when it is dereferenced.\n\nThe proper fix would be in QEMU, but this works around the issue in the\nkernel to keep old setups working, when old kernels had not happened to\nkeep any state in %rdi over the hypercall.\n\nIn theory this same issue exists for all the hypercalls in the vmmouse\ndriver; in practice it has only been seen with vmware_hypercall3() and\nvmware_hypercall4().  For now, just mark RDI/RSI as clobbered for those\ntwo calls.  This should have a minimal effect on code generation overall\nas it should be rare for the compiler to want to make RDI/RSI live\nacross hypercalls."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-02-20T11:31:00.937Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/2f467a92df61eb516a4ec36ee16234dd4e5ccf00"
        },
        {
          "url": "https://git.kernel.org/stable/c/feb603a69f830acb58f78d604f0c29e63cd38f87"
        },
        {
          "url": "https://git.kernel.org/stable/c/2687c848e57820651b9f69d30c4710f4219f7dbf"
        }
      ],
      "title": "x86/vmware: Fix hypercall clobbers",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-23215",
    "datePublished": "2026-02-18T14:21:52.515Z",
    "dateReserved": "2026-01-13T15:37:45.987Z",
    "dateUpdated": "2026-02-20T11:31:00.937Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.