CVE-2026-53199: Linux Hyper-V Network Driver Crash

Technical summary

The vulnerability resides in netvsc_copy_to_send_buf(), which copies packet buffer entries into VMBus send buffers. The function uses phys_to_virt() to translate Hyper-V PFNs into kernel virtual addresses, assuming all referenced pages reside in the kernel's direct map region. However, skb fragments from page cache or user-space pages can live above the LOWMEM boundary on 32-bit x86 systems with CONFIG_HIGHMEM=y, causing phys_to_virt() to return out-of-bounds addresses. The subsequent memcpy() in the transmit softirq path then faults fatally. The fix employs kmap_local_page() for proper page mapping while accounting for two architectural subtleties: (1) pb[i].pfn values are Hyper-V PFNs at 4K granularity, requiring reconstruction to native pages where PAGE_SIZE exceeds 4K (e.g., arm64 with 64K pages), and (2) buffer entries can describe contiguous physical fragments exceeding single page size, necessitating per-page iteration at native page boundaries rather than single-page assumption.

Business impact

This vulnerability causes unscheduled system reboots or hangs in Hyper-V virtual machines transmitting network traffic, directly impacting availability of workloads running on affected hypervisors. For production environments relying on Hyper-V virtualization, particularly those running 32-bit guest systems or mixed 32/64-bit deployments, affected nodes become unreliable during normal operations. Virtual machine uptime expectations, service availability SLAs, and cluster stability are all compromised until remediation. Organizations operating public cloud services or managed infrastructure on Hyper-V face customer impact and potential SLA violations.

Affected systems

The Linux kernel is affected across multiple versions running on Hyper-V hypervisors. The vulnerability specifically impacts 32-bit x86 architectures with CONFIG_HIGHMEM=y enabled, as this configuration allows user-space pages and page cache to reside above the direct-map boundary where phys_to_virt() fails. The issue also affects other architectures with PAGE_SIZE greater than HV_HYP_PAGE_SIZE (4K), such as ARM64 with 64K pages, where the PFN reconstruction logic becomes critical. Verify the specific affected kernel versions and patch availability against the official Linux kernel security advisories.

Exploitability

This is a memory handling flaw triggered during normal network packet transmission—no special conditions, authentication, or user interaction is required. Any workload transmitting network traffic through the Hyper-V virtual network adapter can inadvertently trigger the fault. The vulnerability is highly reliable to exploit in the sense that affected configurations will consistently crash when transmitting packets that reference pages living above the direct-map boundary. No remote code execution is possible; the impact is strictly denial of service through kernel panic.

Remediation

Apply the upstream Linux kernel patch that replaces phys_to_virt() with kmap_local_page()-based page mapping in netvsc_copy_to_send_buf(). This fix handles Hyper-V's 4K PFN granularity correctly and iterates through pages at native page boundaries. For systems unable to update immediately, network traffic can be redirected away from affected virtual machines as a temporary mitigation, though this does not resolve the underlying flaw. Verify the specific kernel version containing the fix against the official Linux kernel repository and your distribution's security advisories.

Patch guidance

Identify your Linux kernel version running on Hyper-V guests using 'uname -r'. Cross-reference this version against the Linux kernel repository (kernel.org) and your distribution's security advisories to locate the patched kernel version incorporating the kmap_local_page() fix for hv_netvsc. Test the patched kernel in a non-production environment with typical network traffic patterns before deploying to production. Hyper-V guests can typically be updated by installing the patched kernel package and rebooting. Coordinate updates to minimize downtime if running in a clustered or load-balanced configuration.

Detection guidance

Monitor system logs and kernel ring buffers for page faults or memory access errors originating from the hv_netvsc driver during network transmission. Look for kernel panic messages referencing netvsc_copy_to_send_buf() or VMBus operations. In virtualized environments, observe unexpected guest reboots or hangs correlated with network activity as potential indicators. Testing on affected hardware with sustained network traffic (large file transfers, high packet rates) can reproduce the fault if the configuration matches the vulnerability conditions (32-bit x86 with high memory or ARM64 with 64K pages).

Why prioritize this

This vulnerability scores 7.5 (HIGH) due to its guaranteed availability impact on affected systems—network transmission faults are fatal and require immediate recovery. While not remotely exploitable in the traditional sense, the lack of authentication or complexity barriers makes it trivial to trigger in any environment running affected kernel versions. For organizations operating Hyper-V infrastructure, particularly data centers with 32-bit guest support or ARM64 hypervisors, this directly threatens service continuity and warrants swift patching. The reliability of the fault and absence of workarounds elevate prioritization.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects HIGH severity: the vulnerability requires no authentication (PR:N) or user interaction (UI:N), operates over the network (AV:N) with low complexity (AC:L), and affects availability only (A:H) without confidentiality or integrity impact. The scope is unchanged (S:U). The score appropriately captures the ease of triggering denial of service in affected environments, though it does not escalate to CRITICAL because remote code execution is not possible and the vulnerability is limited to specific architectural configurations.

Frequently asked questions