WSL2 kernel panic in Hyper-V netvsc receive path with mirrored networking

[Mygod]

Windows Version

Microsoft Windows [Version 10.0.26200.8655]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu-26.04

Other Software

.wslconfig:

[general]
instanceIdleTimeout=86400000

[wsl2]
networkingMode=Mirrored
firewall=false
vmIdleTimeout=86400000
distributionStartTimeout=60000

[experimental]
hostAddressLoopback=true

Additional environment details:

• WSLg is enabled.
• Docker Engine is installed inside WSL.
• A physical ext4 Linux SSD is attached with wsl --mount \\.\PHYSICALDRIVE3 --bare; the distro mounts its ext4 partition at /mnt/mint and bind-mounts /home/mygod from it.
• There is a recurring user systemd service that launches Chromium inside WSL/WSLg for browser automation.
• Windows-side virtual adapter state before mitigation:

Name                          IPv4Enabled IPv6Enabled IPv4OperationalState IPv6OperationalState
vEthernet (External Ethernet) True        True        False                False
Wi-Fi                         True        True        False                False
vEthernet (Default Switch)    True        True        True                 True
vEthernet (FSE HostVnic)      True        True        True                 True

Relevant Windows adapters:

vEthernet (FSE HostVnic): Hyper-V Virtual Ethernet Container Adapter, Up, 10 Gbps
vEthernet (Default Switch): Hyper-V Virtual Ethernet Adapter, Up, 10 Gbps
Ethernet: Realtek Gaming 2.5GbE Family Controller, Up, 2.5 Gbps
WireGuard Tunnel: Up
VMware VMnet1/VMnet8 adapters: Up
Wi-Fi: Disconnected

Repro Steps

I do not yet have a deterministic minimal reproducer. This is the observed sequence:

1. Run WSL2 with networkingMode=Mirrored.
2. Keep the WSL VM running for several days with systemd, Docker, WSLg, and Chromium-based browser automation.
3. At 2026-07-03 03:32:10 -04:00, a systemd user service started a Chromium run inside WSL.
4. At 2026-07-03 03:32:57 -04:00, WSL wrote a kernel panic file under %LOCALAPPDATA%\Temp\wsl-crashes.
5. The WSL VM terminated/restarted. All open WSL terminal tabs exited and running Linux processes were killed.

The immediately preceding distro journal entries were:

2026-07-03T03:32:10-04:00 systemd[289]: Starting service...
2026-07-03T03:32:11-04:00 yarn[3130739]: yarn run v1.22.22
2026-07-03T03:32:15-04:00 systemd[289]: Started app-org.chromium.Chromium-3130789.scope.

There was no Linux shutdown transaction, OOM-killer entry, or systemd poweroff/reboot log before the journal stopped.

Expected Behavior

WSL2 network packet receive processing should not be able to panic the WSL kernel. A user-space Chromium/network workload should either succeed or fail in user space without terminating the entire WSL VM.

Actual Behavior

The WSL VM kernel panicked in the Hyper-V network receive path and the VM was terminated/restarted.

User-visible symptoms:

• Existing WSL terminal tabs exited.
• Running Linux processes were killed.
• After the VM restart, the physical disk attachment was gone, so the distro initially got stuck waiting for mounts until the disk was reattached.

Crash artifact:

Temp\wsl-crashes\kernel-panic-1783063977-{f9f13f23-e524-4dd6-9393-1a6883bfb763}.txt
LastWriteTime: 2026-07-03 03:32:57 -04:00
Length: 3956 bytes

Important excerpt:

[300418.637096] Call Trace:
[300418.637129]  <IRQ>
[300418.637130]  ? netvsc_recv_callback+0x32e/0x3c0
[300418.637961]  rndis_filter_receive+0x216/0x840
[300418.637967]  netvsc_poll+0x2ac/0xba0
[300418.637968]  ? ttwu_do_activate+0x64/0x210
[300418.638066]  __napi_poll+0x2e/0x1c0
[300418.638561]  net_rx_action+0x2a8/0x380
[300418.638563]  handle_softirqs+0xf1/0x2e0
[300418.638597]  __irq_exit_rcu+0x78/0xd0
[300418.638598]  irq_exit_rcu+0x12/0x20
[300418.638599]  sysvec_hyperv_callback+0xb4/0xd0
[300418.638609]  </IRQ>
...
[300418.639652] Modules linked in: nf_conntrack_netlink xt_nat xt_conntrack xt_MASQUERADE xfrm_user xfrm_algo xt_set ip_set xt_addrtype nft_compat intel_rapl_msr intel_rapl_common kvm_intel kvm irqbypass crc32c_intel sch_fq_codel configfs autofs4 br_netfilter bridge stp llc ip_tables tun
[300418.640463] ---[ end trace 0000000000000000 ]---
[300418.640759] RIP: 0010:memcpy+0x11/0x20
...
[300418.640770] Kernel panic - not syncing: Fatal exception in interrupt

Windows System event log at the same time only shows Hyper-V virtual switch NIC/port teardown and recreation. No Windows reboot, sleep/wake transition, storage error, or resource exhaustion event was found around the crash timestamp.

P.S. As a local mitigation, I am considering disabling Receive Segment Coalescing (RSC) on vEthernet (FSE HostVnic), since RSC is currently enabled and the panic occurred in the receive path.

Diagnostic Logs

I can attach the file:

kernel-panic-1783063977-{f9f13f23-e524-4dd6-9393-1a6883bfb763}.txt

I can also provide journalctl -b -1 output around the timestamp if useful.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[Mygod]

/emailed-logs

[github-actions]

Diagnostic information

Found '/emailed-logs', adding tag 'emailed-logs'