CVE-2026-46076 (GCVE-0-2026-46076)
Vulnerability from cvelistv5
Published
2026-05-27 12:58
Modified
2026-08-05 12:29
Severity ?
7.9 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs]
References
Impacted products
Vendor Product Version
Linux Linux Version: 3f4a812edf5cb0a50e65fbdfafdb3e688da18f16
Version: 3f4a812edf5cb0a50e65fbdfafdb3e688da18f16
Version: 3f4a812edf5cb0a50e65fbdfafdb3e688da18f16
Version: 3f4a812edf5cb0a50e65fbdfafdb3e688da18f16
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kvm/hyperv.h",
            "arch/x86/kvm/svm/hyperv.h",
            "arch/x86/kvm/svm/nested.c",
            "arch/x86/kvm/svm/svm.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "924d721fae95687acedbaf624a094ed0e8b67104",
              "status": "affected",
              "version": "3f4a812edf5cb0a50e65fbdfafdb3e688da18f16",
              "versionType": "git"
            },
            {
              "lessThan": "009c0f726abeaa67aad1d96b883bdce01d405ce2",
              "status": "affected",
              "version": "3f4a812edf5cb0a50e65fbdfafdb3e688da18f16",
              "versionType": "git"
            },
            {
              "lessThan": "5fb4a5f361565f5b629d8a8fe5288ce8463c5727",
              "status": "affected",
              "version": "3f4a812edf5cb0a50e65fbdfafdb3e688da18f16",
              "versionType": "git"
            },
            {
              "lessThan": "c36991c6f8d2ab56ee67aff04e3c357f45cfc76c",
              "status": "affected",
              "version": "3f4a812edf5cb0a50e65fbdfafdb3e688da18f16",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kvm/hyperv.h",
            "arch/x86/kvm/svm/hyperv.h",
            "arch/x86/kvm/svm/nested.c",
            "arch/x86/kvm/svm/svm.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.2"
            },
            {
              "lessThan": "6.2",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.86",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.27",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.0.*",
              "status": "unaffected",
              "version": "7.0.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.86",
                  "versionStartIncluding": "6.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.27",
                  "versionStartIncluding": "6.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0.4",
                  "versionStartIncluding": "6.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1",
                  "versionStartIncluding": "6.2",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Raise #UD if unhandled VMMCALL isn\u0027t intercepted by L1\n\nExplicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want\nto intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the\nhypercall is something other than one of the supported Hyper-V hypercalls.\nWhen all of the above conditions are met, KVM will intercept VMMCALL but\nnever forward it to L1, i.e. will let L2 make hypercalls as if it were L1.\n\nThe TLFS says a whole lot of nothing about this scenario, so go with the\narchitectural behavior, which says that VMMCALL #UDs if it\u0027s not\nintercepted.\n\nOpportunistically do a 2-for-1 stub trade by stub-ifying the new API\ninstead of the helpers it uses.  The last remaining \"single\" stub will\nsoon be dropped as well.\n\n[sean: rewrite changelog and comment, tag for stable, remove defunct stubs]"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.9,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The path is reached by executing a VMMCALL instruction from within a nested (L2) guest running under KVM on AMD SVM; this is local execution against the hypervisor, not reachable via network, adjacent network, or physical interface.\nAC:L - Triggering is deterministic \u2014 once the nested setup exists (L1 does not intercept VMMCALL, e.g. relying on L0\u0027s Hyper-V direct L2 TLB-flush handling), a single VMMCALL in L2 reliably reaches L0\u0027s hypercall handler with no race or attacker-uncontrolled timing, mirroring sibling CVE-2026-43133.\nPR:L - The attacker must control a guest and run guest kernel-level (CPL0) code in the nested guest to set up and issue the hypercall; this is low privilege relative to the host and requires no real init-namespace root.\nUI:N - Exploitation is triggered solely by guest instruction execution (VMMCALL); no host-side or victim user action is required.\nS:C - The bug is in KVM\u0027s enforcement of the nested-virtualization boundary: L2\u0027s VMMCALL is serviced by L0 as if it were L1 instead of #UD\u0027ing, so an L2 guest\u0027s action reaches and affects L1/L0-maintained state outside the L2 guest\u0027s own security authority.\nC:L - The improperly-handled hypercalls cause L0 to read L1-context memory (guest-physical addresses supplied by L2 are interpreted in the L1/host-maintained address space) and inspect the vCPU\u0027s Hyper-V state \u2014 a bounded cross-domain exposure, not an arbitrary host read primitive.\nI:L - L2 can drive L0 hypercalls that modify L1/host-maintained state (inject IPIs into the VM\u0027s vCPUs, post SynIC messages/signal events, request GPA-range operations), a bounded cross-domain state modification rather than an arbitrary write or code-execution primitive.\nA:H - L2 can repeatedly issue these hypercalls to force TLB flushes, inject IPIs, and corrupt the L1 hypervisor\u0027s Hyper-V messaging state, destabilizing or hanging the affected nested-virtualization workload at will \u2014 a complete loss of availability for that workload."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:29:29.930Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/924d721fae95687acedbaf624a094ed0e8b67104"
        },
        {
          "url": "https://git.kernel.org/stable/c/009c0f726abeaa67aad1d96b883bdce01d405ce2"
        },
        {
          "url": "https://git.kernel.org/stable/c/5fb4a5f361565f5b629d8a8fe5288ce8463c5727"
        },
        {
          "url": "https://git.kernel.org/stable/c/c36991c6f8d2ab56ee67aff04e3c357f45cfc76c"
        }
      ],
      "title": "KVM: nSVM: Raise #UD if unhandled VMMCALL isn\u0027t intercepted by L1",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-46076",
    "datePublished": "2026-05-27T12:58:09.169Z",
    "dateReserved": "2026-05-13T15:03:33.096Z",
    "dateUpdated": "2026-08-05T12:29:29.930Z",
    "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.