CVE-2026-53199 in Linux
Summary
by MITRE • 06/25/2026
In the Linux kernel, the following vulnerability has been resolved:
hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf
netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal.
Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries:
- pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity,
not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages).
- Since commit 41a6328b2c55 ("hv_netvsc: Preserve contiguous PFN grouping in the page buffer array"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE,
while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries.
The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 06/25/2026
The vulnerability in question affects the Linux kernel's Hyper-V network virtualization driver, specifically within the hv_netvsc module responsible for managing network traffic between virtual machines and the host system. This issue manifests as a critical fault condition during packet transmission that can lead to system crashes or denial of service. The problem occurs when processing skb (socket buffer) fragments that reference page cache or user pages, particularly on 32-bit x86 systems configured with CONFIG_HIGHMEM=y where these pages may exist beyond the LOWMEM boundary.
The technical flaw stems from improper memory mapping during packet transmission operations within the netvsc_copy_to_send_buf() function. When this function processes page buffer entries for transmission, it uses phys_to_virt() to convert physical frame numbers (PFNs) into virtual addresses for copying data into the VMBus send buffer. This approach fails for pages located above the LOWMEM boundary on 32-bit systems because phys_to_virt() returns addresses that fall outside the kernel's direct map range, causing memory access violations during the subsequent memcpy() operation on the transmit softirq path. This represents a fundamental failure in memory management that violates the expected behavior of kernel networking subsystems and can be classified under CWE-129 as improper validation of array indices or buffer bounds.
The operational impact of this vulnerability is severe as it affects the stability and reliability of virtualized network communications. The fault occurs during critical packet transmission paths, specifically on the softirq processing thread which handles network transmit operations in interrupt context. This means that any attempt to send network packets through affected Hyper-V virtual interfaces can trigger immediate system crashes or kernel oops conditions, effectively rendering the network interface unusable until the system is rebooted. The vulnerability particularly affects systems running 32-bit x86 kernels with high memory support enabled, making it relevant to a significant portion of enterprise virtualization deployments.
The fix implemented addresses the core memory mapping issue by replacing phys_to_virt() calls with kmap_local_page() for proper page mapping in the network transmit path. This solution properly handles two critical aspects of the page buffer entries that were previously inadequately addressed. First, it correctly processes Hyper-V PFNs which operate at 4KB granularity regardless of native page size, requiring reconstruction of the actual physical address before deriving the correct native page reference for mapping. Second, it accounts for the change introduced in commit 41a6328b2c55 that allows entries to describe physically contiguous fragments larger than standard page boundaries, necessitating page-by-page copying operations that respect native page boundaries rather than attempting to map entire large fragments at once.
The solution's design ensures compatibility across different architectures and kernel configurations while maintaining performance characteristics. On systems where CONFIG_HIGHMEM is disabled, kmap_local_page() effectively maps to page_address() which provides the same functionality without additional overhead, ensuring no performance regression on non-affected configurations. The implementation correctly handles the constraint that packet copies are limited to the send section size of 6144 bytes by default, with larger packets taking a different code path that only copies the RNDIS header and thus avoids the problematic page mapping scenario. This approach aligns with established kernel security practices for memory management in high-performance networking contexts and follows ATT&CK technique T1059.001 for execution through system commands while maintaining proper kernel memory access patterns that prevent unauthorized memory access violations.
The remediation represents a significant improvement over the original implementation's approach to virtual memory management in network driver code, ensuring that memory operations remain within safe kernel address spaces regardless of physical page location or system configuration parameters. The fix prevents the fatal memory faults that would otherwise occur during packet transmission and restores normal network functionality for Hyper-V virtual machines, particularly those running on 32-bit x86 systems with high memory support enabled. This vulnerability resolution demonstrates the critical importance of proper memory mapping techniques in kernel networking drivers where incorrect assumptions about memory layout can lead to system instability and security implications.