New WSL sessions hang under memory pressure with vmbus_alloc_ring allocation failure

@chessturo is already working on this.

Since Jun 16, 2026.

### AI disclosure

This report was drafted and filed with assistance from OpenAI Codex, based on local command output and logs from the affected machine.

### Summary

WSL semi-routinely gets into a state where existing WSL shells continue to work, but new WSL sessions and Windows interop hang. This appears to correlate with memory pressure and a kernel `vmbus_alloc_ring` allocation failure.

This looks similar to #11612. It has similar outer symptoms to #12991, but Docker Desktop is already newer than the Docker Resource Saver fix discussed there and in docker/for-win#14656.

### Environment

- WSL 2
- Distro: Ubuntu 24.04.3 LTS
- Kernel: `6.18.33.1-microsoft-standard-WSL2`
- `.wslconfig`: `memory=52GB`
- Docker Desktop: `4.44.3`
- Docker Engine / CLI: `28.3.2`
- Docker Compose: `v2.39.1-desktop.1`
- Docker Desktop WSL bootstrap: `098d711f2ff00f0a1c4d69da1f9d6d2d`
- Windows / WSL app version: not collected while wedged because `wsl.exe --status` and `wsl.exe -l -v` hang

### Behavior

After some time under normal dev workload, apparently under memory pressure:

- existing WSL shells still run commands
- opening new WSL terminals hangs
- launching `wsl.exe` from WSL hangs
- launching Windows interop commands such as `cmd.exe /c echo cmd-ok` from WSL hangs
- recovery requires `wsl --shutdown` or restarting WSL services / rebooting

### Relevant local checks

```text
$ timeout 8 bash -lic 'printf shell-ok'
shell-ok

$ timeout 12 /mnt/c/Windows/System32/wsl.exe -d Ubuntu --exec /bin/bash -lc 'printf wsl-exec-ok'
<3>WSL (...) ERROR: UtilAcceptVsock:273: accept4 failed 110

$ timeout 10 /mnt/c/Windows/System32/wsl.exe --status
# timed out, no output

$ timeout 10 /mnt/c/Windows/System32/wsl.exe -l -v
# timed out, no output

$ timeout 8 /mnt/c/Windows/System32/cmd.exe /c echo cmd-ok
# timed out, no output
```

### Journal excerpts

Repeated session leader failures:

```text
Jun 12 10:04:35 ... WSL (849628 - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
Jun 12 10:04:35 ... WSL (849628 - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110
Jun 12 10:04:44 ... WSL (849732 - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
Jun 12 10:04:44 ... WSL (849732 - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110
Jun 12 15:47:51 ... WSL (1042443 - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
Jun 12 15:47:51 ... WSL (1042443 - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110
Jun 12 17:10:40 ... WSL (1059662 - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
Jun 12 17:10:40 ... WSL (1059662 - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110
```

Earlier memory / Hyper-V socket allocation failure:

```text
Jun 11 17:40:07 ... kernel: kworker/0:0: page allocation failure: order:7, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0
Jun 11 17:40:07 ... kernel: Workqueue: hv_pri_chan vmbus_add_channel_work
Jun 11 17:40:07 ... kernel: vmbus_alloc_ring+0x78/0xd0
Jun 11 17:40:07 ... kernel: vmbus_open+0x29/0x80
Jun 11 17:40:07 ... kernel: hvs_probe+0x1f4/0x4c0
Jun 11 17:40:07 ... kernel: vmbus_probe+0x42/0xa0
Jun 11 17:40:07 ... kernel: vmbus_device_register+0x87/0x130
Jun 11 17:40:07 ... kernel: vmbus_add_channel_work+0x146/0x1d0
```

Mem-Info from the same allocation failure showed heavy pressure near the WSL memory cap:

```text
active_anon:114025 inactive_anon:11507801 isolated_anon:32
active_file:1031583 inactive_file:146747 isolated_file:0
free:60986 free_pcp:1372 free_cma:0
Node 0 active_anon:456100kB inactive_anon:46031204kB active_file:4126332kB inactive_file:586988kB
Node 0 Normal free:46896kB min:41688kB low:91140kB high:140592kB
Node 0 Normal: ... 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44724kB
Free swap = 12716576kB
Total swap = 13631488kB
```

The same allocation failure repeated at least two more times:

```text
Jun 11 17:41:42 ... kernel: kworker/0:3: page allocation failure: order:7, mode:0xdc0(GFP_KERNEL|__GFP_ZERO)
Jun 11 17:41:42 ... kernel: Workqueue: hv_pri_chan vmbus_add_channel_work
Jun 11 17:41:42 ... kernel: vmbus_alloc_ring+0x78/0xd0
Jun 11 17:41:58 ... kernel: kworker/0:2: page allocation failure: order:7, mode:0xdc0(GFP_KERNEL|__GFP_ZERO)
Jun 11 17:41:58 ... kernel: Workqueue: hv_pri_chan vmbus_add_channel_work
Jun 11 17:41:58 ... kernel: vmbus_alloc_ring+0x78/0xd0
```

### Notes

Docker Desktop is installed and WSL integration is active, but the installed Docker Desktop version is `4.44.3`, newer than the `4.42.1` fix referenced from #12991 / docker/for-win#14656. This may still be Docker-triggered, but the local kernel evidence looks closer to #11612: `vmbus_alloc_ring` cannot allocate under memory pressure, then WSL session creation / interop starts timing out.