Look up another CVE · open CVE-2026-53199 in the interactive tracker
CVE-2026-53199
hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-53199 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4665-1 · 2026-07-03 · text | 6.1.176-1 | Update the kernel and reboot. DLA-4665-1 shipped the fix on 2026-07-03, in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/hyperv/netvsc.c
- What this is
- Hyper-V/Azure CORE AND DRIVERSMAINTAINERS section matched on drivers/net/hyperv/ · linux-hyperv@vger.kernel.org · Supported
- Kernel module
- hv_netvsc
Check it on the machine
grep -w CONFIG_HYPERV_NET /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w hv_netvscPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixieMnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_HYPERV_NET
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-06-25 (4 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.50%, higher than 41.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.16 | 5.10.259 | 16514afeb7d3 |
| 3.16 | 5.15.210 | a82d4251918f |
| 3.16 | 6.1.176 | 695c59cf7bf7 |
| 3.16 | 6.6.143 | 09b8a7aa5a34 |
| 3.16 | 6.12.94 | 918c0c988239 |
| 3.16 | 6.18.36 | 0b38870d81ab |
| 3.16 | 7.0.13 | fe7221b43464 |
| 3.16 | 7.1 | 004e9ecfe6c5 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4671-1 | 2026-07-05 | bullseye 6.1.176-1~deb11u1 | tracker |
| DLA-4665-1 | 2026-07-03 | bookworm 6.1.176-1 | tracker |
| DLA-4664-1 | 2026-07-03 | bullseye 5.10.259-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- An unauthenticated remote peer can induce a Hyper-V guest providing a network service to transmit TCP responses through hv_netvsc, reaching the normal netdev transmit path and netvsc_copy_to_send_buf. No local ioctl or device-file access is required in that reasonable deployment.
- AC:LAttack complexity, low
- The fault is deterministic once a small send-buffer-copied skb contains a highmem-backed fragment, which ordinary TCP/file-send paths can create on affected 32-bit HIGHMEM guests. Any uncertainty about allocation timing is resolved toward Low because the attacker can repeatedly trigger outbound sends.
- PR:NPrivileges required, none
- In the remote-service scenario, the attacker needs only network access to the exposed service and no account or kernel capabilities on the guest. The driver path itself performs no privilege check.
- UI:NUser interaction, none
- No victim action is required beyond the target system already running with the Hyper-V netvsc interface and serving network traffic. The attacker triggers transmission by sending network requests.
- S:UScope, unchanged
- The impact is within the vulnerable guest kernel and its networking stack. The bug does not cross into the Hyper-V host or another security authority.
- C:NConfidentiality impact, none
- The vulnerable operation is an invalid source mapping from phys_to_virt for a highmem page, and the documented effect is a fault in memcpy. I found no credible primitive for reading protected data before the fatal fault.
- I:NIntegrity impact, none
- The destination is the preallocated netvsc send buffer and the bug does not corrupt kernel control data or provide an arbitrary write. The demonstrated impact is not data modification.
- A:HAvailability impact, high
- The invalid memcpy source faults on the transmit softirq path and the fix commit describes this as fatal. A kernel oops or panic from remotely triggerable network transmission is High availability impact.