CVE-2026-53199

What it actually does

This flaw is a Linux kernel denial-of-service issue in the Hyper-V network driver, hv_netvsc. During packet transmission, netvsc_copy_to_send_buf() incorrectly used phys_to_virt() to access packet fragment pages. On systems where packet fragments may reside outside the kernel direct map, especially 32-bit x86 kernels built with CONFIG_HIGHMEM=y, this can produce an invalid virtual address. The subsequent memcpy() occurs in the transmit softirq path and can trigger a kernel fault or panic, crashing the affected guest. The fix changes the code to map pages safely with kmap_local_page() and correctly handles Hyper-V PFN granularity and fragments spanning native page boundaries.

Why it matters to the business

Successful exploitation can crash affected Linux virtual machines using the Hyper-V synthetic network driver, causing service interruption, dropped network connectivity, workload restarts, and potential availability incidents. The practical risk is concentrated in Linux guests running on Hyper-V/Azure-like virtualization stacks, particularly uncommon 32-bit high-memory kernel configurations. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, so it should be prioritized primarily for exposed or availability-critical systems that match the affected driver and kernel configuration.

How an attack unfolds

An attacker must cause an affected Linux guest to transmit network packets whose skb fragments reference pages not safely addressable through the direct kernel map. This is most plausible from local code running inside the guest, such as an unprivileged process generating network traffic through APIs that can create fragmented skbs from page cache or user-backed pages. In some workloads, a remote party may indirectly influence transmission by causing the server to send responses, but exploitation depends heavily on kernel architecture, CONFIG_HIGHMEM, driver use, and packet construction. When the vulnerable transmit path handles the packet, hv_netvsc attempts to copy fragment data into the Hyper-V VMBus send buffer using an invalid direct-map address. The resulting memcpy fault occurs in softirq context and can be fatal, leading to a guest kernel oops or panic rather than code execution.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the hv_netvsc fix changing netvsc_copy_to_send_buf() to use kmap_local_page() and correctly split copies across native page boundaries. Because no exact package versions were provided, use the fixed kernel versions published by the relevant distribution or cloud image vendor. Prioritize kernels used by Linux guests on Hyper-V or Azure-like platforms, especially 32-bit x86 kernels with CONFIG_HIGHMEM=y. Where immediate patching is not possible, reduce exposure by migrating critical workloads away from affected 32-bit high-memory kernels, using a patched kernel image, disabling or replacing affected guest images, and limiting untrusted local code execution that can generate arbitrary network traffic. Disabling networking is generally not a practical mitigation for production systems.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for hv_netvsc/netvsc_copy_to_send_buf() or verify the source contains kmap_local_page() usage in that function instead of direct phys_to_virt() copying of skb fragment pages. Validate whether systems are in scope by checking for the hv_netvsc module or driver, Hyper-V virtualization, 32-bit x86 architecture, and CONFIG_HIGHMEM=y. After patching, reboot into the fixed kernel and confirm the old vulnerable kernel is no longer running. Review package manager history and kernel version inventory to ensure all affected guest images and templates have been updated, not just active instances.

Typical attack path

1. Identify or assume a Linux guest using the Hyper-V hv_netvsc network driver.
2. Trigger network transmission from the guest using traffic patterns that create skb fragments backed by high memory, page cache, or user pages.
3. Cause the vulnerable netvsc_copy_to_send_buf() transmit-copy path to process the fragmented packet.
4. The driver resolves a fragment PFN with phys_to_virt() even though the page is not safely available in the direct map.
5. memcpy() faults in the transmit softirq path.
6. The guest kernel oopses or panics, resulting in denial of service.

How to detect it

Look for evidence of kernel oops, panic, or watchdog events associated with the Hyper-V network driver transmit path. Useful sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, crash dumps from kdump/vmcore, hypervisor VM reset or heartbeat-loss events, and monitoring alerts for sudden guest reboot or network loss. Search for stack traces containing netvsc_copy_to_send_buf, hv_netvsc, netvsc_send, memcpy, softirq, or page fault messages. Because this issue causes a crash rather than a persistent compromise, there may be no file-system artifact or durable IOC beyond kernel logs and crash dumps. Correlate suspected crashes with processes or users generating high-volume outbound traffic, sendfile/splice-style transfers, web responses serving files, or other workloads that can produce fragmented skb transmissions.

• netvsc_copy_to_send_buf
• hv_netvsc
• netvsc_send
• netvsc_xmit
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• Oops:
• Kernel panic - not syncing
• RIP: netvsc_copy_to_send_buf
• EIP: netvsc_copy_to_send_buf
• memcpy
• NETDEV WATCHDOG
• softirq
• /var/log/kern.log
• /var/log/messages
• vmcore
• kdump

What your security team should do

• Inventory Linux guests using the hv_netvsc Hyper-V network driver and identify any 32-bit x86 kernels built with CONFIG_HIGHMEM=y.
• Prioritize patching for availability-critical workloads, multi-tenant systems, and hosts that allow untrusted local users or workloads to generate network traffic.
• Update golden images, VM templates, autoscaling images, and recovery images so new instances do not boot vulnerable kernels.
• Monitor kernel logs for crashes involving hv_netvsc, netvsc_copy_to_send_buf(), memcpy(), or transmit softirq faults.
• If crashes are observed, preserve kernel logs, vmcore/kdump output, and recent network workload activity before reboot evidence is lost.
• Track vendor advisories for exact fixed kernel package versions and apply the fixed release during the next emergency or expedited maintenance window for in-scope systems.