CVE-2026-43045

What it actually does

This is a Linux kernel memory-corruption flaw in the mshv hypervisor driver’s handling of pinned user pages. When pin_user_pages_fast() returns fewer pinned pages than requested, the vulnerable code treats the partial result as success and may operate on an incomplete memory region. In some error paths, already pinned pages are also not correctly accounted for before invalidation, causing page reference leaks. The most likely security consequence is a local denial of service through kernel memory corruption, kernel crash, or resource exhaustion. The CVSS vector indicates local access with low privileges is required, no user interaction is needed, and availability impact is high.

Why it matters to the business

Systems running affected Linux kernel builds with the vulnerable mshv functionality exposed may be susceptible to local crashes or instability caused by a low-privileged user or process. In production, this can translate into host outages, failed workloads, disrupted virtualization-related services, and emergency reboots. The current EPSS is very low, has been flat over 30 days, is not listed in CISA KEV, and has no known public exploit maturity, so this is not currently an internet-scale emergency; however, kernel availability bugs should still be prioritized on multi-user systems, virtualization hosts, and environments where untrusted local code can run.

How an attack unfolds

An attacker first needs local code execution on a system using an affected Linux kernel and access to the vulnerable mshv interface or functionality. The attacker then causes mshv_region_pin to attempt to pin a region of user memory under conditions where pin_user_pages_fast() can return a short positive pin count rather than pinning every requested page. Because the vulnerable code treats that short pin as successful, subsequent operations may use a partially pinned region, corrupting kernel memory or triggering inconsistent state. Alternatively, repeated triggering of error paths can leak page references, contributing to resource exhaustion. Practical exploitation is expected to focus on crashing the kernel or degrading availability rather than stealing data or directly escalating privileges, based on the published impact and CVSS scope.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for mshv_region_pin error handling. The fix should treat short pin_user_pages_fast() results as failures and correctly account for partially pinned batches before cleanup. No exact fixed package versions were provided in the input, so use the fixed kernel releases from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintenance branch. Where immediate patching is not possible, reduce exposure by disabling or restricting access to mshv functionality if it is not required, limiting local shell/container access to trusted users, applying least-privilege controls, and scheduling reboots into a patched kernel as soon as maintenance windows allow. Mitigation should not be considered equivalent to patching because the flaw is in kernel memory-management error handling.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed package, is a vendor build containing the mshv_region_pin fix. Check kernel package changelogs or vendor advisories for references to the mshv_region_pin short-pin handling fix. Validate that systems have been rebooted into the patched kernel after installation. For exposure assessment, determine whether affected kernel versions are deployed and whether mshv support is present or loaded. Review whether untrusted users, containers, or workloads can execute code locally on those systems. Functional validation may include confirming that the relevant mshv module or built-in driver is patched, but avoid attempting destructive proof-of-concept testing on production systems because successful triggering may crash the host.

Typical attack path

1. Gain local execution as a low-privileged user or through a compromised local workload.
2. Identify whether the running kernel exposes or uses the vulnerable mshv functionality.
3. Interact with the mshv interface in a way that requests user-page pinning for controlled memory regions.
4. Force or induce partial page-pinning behavior or mid-loop error handling conditions.
5. Trigger use of an incompletely pinned region or repeated cleanup errors.
6. Cause kernel memory corruption, kernel oops/panic, host instability, or resource exhaustion.

How to detect it

To determine whether this was already exploited, review host-level telemetry rather than network logs, because exploitation requires local interaction and is not expected to have a distinctive remote signature. Collect kernel logs from journalctl, dmesg, /var/log/kern.log, /var/log/messages, and crash dump infrastructure such as kdump, apport, abrt, or systemd-coredump. Look for kernel oops, panic, BUG, WARNING, general protection fault, page reference leak, refcount, use-after-free, or memory corruption messages temporally associated with mshv activity or untrusted local workloads. Correlate crashes with process accounting, auditd, sudo logs, EDR process telemetry, container runtime logs, and hypervisor-related access to determine which local process invoked the relevant device or interface before instability. Because no public exploit or actor-specific tradecraft is indicated, absence of a named IOC does not prove absence of exploitation; focus on crash timing, repeated reproducible local crashes, suspicious local binaries, and anomalous access to mshv-related device nodes or modules.

• mshv_region_pin
• pin_user_pages_fast
• mshv
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• BUG: unable to handle page fault
• refcount_t: underflow
• page_ref
• bad page state
• /dev/mshv

What your security team should do

• Inventory Linux systems running kernels that include mshv support, prioritizing virtualization hosts, multi-tenant systems, CI runners, developer workstations, and servers that allow local untrusted code execution.
• Apply vendor kernel updates that include the mshv_region_pin fix and reboot systems into the patched kernel.
• If patching is delayed, restrict local access, remove unnecessary users, harden container escape boundaries, and disable or restrict mshv functionality where operationally feasible.
• Monitor kernel logs for oops, panic, page reference, memory corruption, or mshv-related errors, especially on systems with local multi-user or workload execution.
• Because EPSS is low, KEV status is false, and no mature exploit is reported, prioritize based on local exposure and availability criticality rather than treating it as active mass exploitation.
• Ensure incident response runbooks treat unexplained kernel crashes on exposed systems as potentially security-relevant until logs and workload activity are reviewed.