Kernel BUG at fs/namei.c:844 (try_to_unlazy) after 9P/virtiofs channel disruption causes WSL2 crash

Windows Version

Microsoft Windows [版本 10.0.26200.8894]

WSL Version

WSL 版本: 2.9.4.0 内核版本: 6.18.35.2-1 WSLg 版本: 1.0.79 MSRDC 版本: 1.2.7214 Windows 版本: 10.0.26200.8894

Are you using WSL 1 or WSL 2?

WSL 2
WSL 1

Kernel Version

6.18.35.2-microsoft-standard-WSL2 (gcc 13.2.0, #1 SMP PREEMPT_DYNAMIC Wed Jun 17 23:14:00 UTC 2026)

Distro Version

Debian 11 (bullseye)

Other Software

Docker Engine 29.6.2 (running natively inside WSL2, not Docker Desktop)
Docker Buildx (docker-container driver, BuildKit v0.31.2)
.wslconfig: networkingMode=mirrored, dnsTunneling=true, memory=16G, autoMemoryReclaim=Gradual

Repro Steps

Configure .wslconfig with networkingMode=mirrored and dnsTunneling=true
Create a Docker buildx builder with docker-container driver:
docker buildx create --name czy-builder --driver docker-container --use
--platform linux/amd64,linux/arm64 --config ./buildkitd.toml
Run a heavy cross-platform Docker build (ARM64 FreeSWITCH compilation):
docker buildx build --builder czy-builder --platform linux/arm64
--progress=plain --target release -t freeswitch:release.v1.10.7-arm64
-f Dockerfile.freeswitch.arm --load .
After ~10-15 minutes of heavy build I/O, observe DNS resolution failures in dmesg:
"WSL (135) ERROR: CheckConnection: getaddrinfo() failed: -5"
Shortly after, the 9P/virtiofs channel disrupts:
"Exception: Operation canceled @p9io.cpp:258 (AcceptAsync)"
WSL receives SIGTERM and shuts down uncleanly.
After WSL restart, running ls or any path lookup triggers a kernel BUG:
"kernel BUG at fs/namei.c:844!"
"Oops: invalid opcode: 0000 [Will this be Open Source? #1] SMP NOPTI"
"RIP: 0010:try_to_unlazy+0xbc/0xe0"
Call trace: statx → vfs_statx → filename_lookup → path_lookupat → complete_walk → try_to_unlazy → BUG()
WSL crashes again.

Expected Behavior

After a 9P channel disruption and WSL restart, the kernel should properly clean up VFS dentry cache state. Path lookup operations (ls, statx) should work normally without triggering a kernel BUG/oops. The VFS state machine should not enter an invalid state after 9P/virtiofs reconnection.

Actual Behavior

After 9P/virtiofs channel disruption and subsequent WSL restart, the VFS dentry cache retains corrupted/stale state from the unclean shutdown. When any process performs a path lookup (e.g., ls invoking statx syscall), the RCU-walk to refcounted-walk transition via try_to_unlazy() detects an invalid nameidata state (RAX=4, expected LOOKUP_RCU=1) and triggers kernel BUG at fs/namei.c:844. This causes a kernel oops (invalid opcode 0000 [#1]) which destabilizes the entire WSL VM, leading to cascading Docker exec failures ("broken pipe" errors on /run/docker.sock) and eventual WSL crash.

Key evidence from dmesg/kern.log:

Pre-crash DNS failures (11 min before crash):

WSL (135) ERROR: CheckConnection: getaddrinfo() failed: -5
9P channel disruption:

Exception: Operation canceled @p9io.cpp:258 (AcceptAsync)
systemd-journald: Received SIGTERM from PID 1 (systemd-shutdow)
EXT4-fs (sdd): unmounting filesystem
Unclean shutdown confirmed on restart:

EXT4-fs (sdd): recovery complete
systemd-journald: File ... corrupted or uncleanly shut down, renaming and replacing
Kernel BUG (the actual crash):

kernel BUG at fs/namei.c:844!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 7 UID: 0 PID: 13059 Comm: ls Not tainted 6.18.35.2-microsoft-standard-WSL2
RIP: 0010:try_to_unlazy+0xbc/0xe0
RAX: 0000000000000004 RBX: ... RCX: 0000000000000000
Call Trace:
complete_walk+0x43/0xb0
path_lookupat+0x9c/0x180
filename_lookup+0xe2/0x1e0
vfs_statx+0x69/0x100
do_statx+0x48/0x80
__x64_sys_statx+0xa6/0xf0
do_syscall_64+0x73/0x990
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Cascading Docker failures (symptom, not root cause):

Error running exec ... in container: exec attach failed:
error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe
The root cause chain: 9P channel disruption → unclean shutdown → corrupted dentry cache on restart → try_to_unlazy() kernel BUG → WSL crash.

Diagnostic Logs

Jul 28 09:04:46 Czy dockerd[337]: time="2026-07-28T09:04:46.905085596+08:00" level=error msg="Error running exec 91a72f1c5fe04ee3273788755f4670c7f624c1d032740cd8690635f5dcafa82e in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:05:42 Czy dockerd[337]: time="2026-07-28T09:05:42.465224432+08:00" level=error msg="Error running exec 6f12c1b3d78b133f6cc80ba405726883abd176c2be70ed2015ea47defbc87b24 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:05:43 Czy dockerd[337]: time="2026-07-28T09:05:43.120458637+08:00" level=error msg="Error running exec c1f8e87b5ae2ca7f7aa9a7c6a80f4c245ee5d9430b7f741c9a6901907bce195e in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:05:49 Czy dockerd[337]: time="2026-07-28T09:05:49.145823298+08:00" level=error msg="Error running exec cb2fb83734dca1bbd9537d1ac31f61ec50d7e62ff8d4826b5f71c32537dbfc98 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:05:54 Czy dockerd[337]: time="2026-07-28T09:05:54.021885442+08:00" level=error msg="Error running exec d136143004c8e7ef628eb18097c1dac598e0be7babb8d1ec9e76cc7c46d4d120 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:05:54 Czy dockerd[337]: time="2026-07-28T09:05:54.467607410+08:00" level=error msg="Error running exec 04add2ac4e6cd6c77a6deca49bec1f223b08494a838d4a7b1b28c46e80ffdc3a in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:05:58 Czy dockerd[337]: time="2026-07-28T09:05:58.708408283+08:00" level=error msg="Error running exec 86dc9e36f946e642cc82b46b078e5ff9cddd7b660a0fafac35597ec52929260f in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:05 Czy dockerd[337]: time="2026-07-28T09:06:05.272092583+08:00" level=error msg="Error running exec 3cf6496bfe8c79fb3566ca81a22a117dc4610f859b50b9d6d00f259ae91dff55 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:08 Czy dockerd[337]: time="2026-07-28T09:06:08.798769249+08:00" level=error msg="Error running exec 70dfd6b4195c2cc44b9f56bd5f2b5474b8098a48f5fec299a09b0f35803ff8e5 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:09 Czy dockerd[337]: time="2026-07-28T09:06:09.200837648+08:00" level=error msg="Error running exec d1e544dcebf5e87b5c585d97f857fb111ceba6543cb1381cd7ce85ef0a70c466 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:09 Czy dockerd[337]: time="2026-07-28T09:06:09.580226610+08:00" level=error msg="Error running exec d04200f79434933d2d03deba28e44fc0355a024a3aab730231fa4ac35e34c8f4 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:10 Czy dockerd[337]: time="2026-07-28T09:06:10.629489394+08:00" level=error msg="Error running exec 02f04a6a347eb1973feb83f44f40ebdf87cc94f845eef990ef0680f020eb3786 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:14 Czy dockerd[337]: time="2026-07-28T09:06:14.034117897+08:00" level=error msg="Error running exec 38d1fe09b7d9e30f0dca094e46c66616414e4527177c2ed95f175d5b5bd030c2 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:14 Czy dockerd[337]: time="2026-07-28T09:06:14.390404874+08:00" level=error msg="Error running exec 3b986fd642f4b21292edd6906d16a4fe6985dcd3805d6f5faeef827234c89b98 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:18 Czy dockerd[337]: time="2026-07-28T09:06:18.613831694+08:00" level=error msg="Error running exec 7f2a89381ef0fdddfb3f54e946a6ef281554ecc213d8078575b48580e351c047 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:19 Czy dockerd[337]: time="2026-07-28T09:06:19.019165881+08:00" level=error msg="Error running exec 7bb0f06cdefb048095ea5f84645267e1b9c85843469bd376fbdf1b4949498337 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:31 Czy dockerd[337]: time="2026-07-28T09:06:31.450865656+08:00" level=error msg="Error running exec b1213c9d315b7bbf8892c7bf5dc5abfbff91bc94e6b2cb281335c29bce9521fe in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:31 Czy dockerd[337]: time="2026-07-28T09:06:31.934497341+08:00" level=error msg="Error running exec 175072500b4a3f30c40aa6e40344a0debbe8f71bbfaebb6124ff76a90ce17a5f in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:40 Czy dockerd[337]: time="2026-07-28T09:06:40.474017132+08:00" level=error msg="Error running exec 7ac15c62005a8501b93883731b5e2aaf55edb080e0ec696ba0ce7c10093fbafc in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:42 Czy dockerd[337]: time="2026-07-28T09:06:42.106268910+08:00" level=error msg="Error running exec 48437c668b6eebe1a36dae009cc55c8ded66bbe1b5deb58c941a271f2d10560b in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:06:55 Czy dockerd[337]: time="2026-07-28T09:06:55.559441102+08:00" level=error msg="Error running exec 0631fe16cbc2ce1feba5285ee7f7f7d61d7e43a17e274c6ac90f4aab493cc191 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:02 Czy dockerd[337]: time="2026-07-28T09:07:02.733350827+08:00" level=error msg="Error running exec 8980210a373f249fce5b386f0e01ed760a287869d30535f528e8cb90ef17de81 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:07 Czy dockerd[337]: time="2026-07-28T09:07:07.283785971+08:00" level=error msg="Error running exec 5ec1431c97a6f745e8a92b8073e78b22eb9ee03fcb035de0239814f17be98774 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:08 Czy dockerd[337]: time="2026-07-28T09:07:08.378367489+08:00" level=error msg="Error running exec 7e655a4aba120455ef9f6a39040890cbacc280761da2edb9876c377ffaa58611 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:08 Czy dockerd[337]: time="2026-07-28T09:07:08.793486111+08:00" level=error msg="Error running exec b8095fca8668a32a0a8ab5c910cc18cbdf197ea1e935f52aa7344ca5dea5d5e3 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:12 Czy dockerd[337]: time="2026-07-28T09:07:12.025938374+08:00" level=error msg="Error running exec 2d0073a0fc957920eeff4e82b9a84e8dc14c1ff19a55edfb62d95b76f23be1fc in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:12 Czy dockerd[337]: time="2026-07-28T09:07:12.429610737+08:00" level=error msg="Error running exec d2107f8d37127b9512595ec82d1a641feaa952066e007b8ff088ec3c005e9c80 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:12 Czy dockerd[337]: time="2026-07-28T09:07:12.797375886+08:00" level=error msg="Error running exec 34d3e2344d828622b81a68a54eb4dc88900c18ef82685f0479a70fbad95cd2a6 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:17 Czy dockerd[337]: time="2026-07-28T09:07:17.979649012+08:00" level=error msg="Error running exec 4ddc657f651a15f7d016ddd09d597ffcb2907b18f61b96730e8654f75612812c in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:19 Czy dockerd[337]: time="2026-07-28T09:07:19.088706104+08:00" level=error msg="Error running exec 137ff8b21cf835306d3931b2b34708f57d827fdda12b4fe380ed13edccf10d62 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:32 Czy dockerd[337]: time="2026-07-28T09:07:32.469548095+08:00" level=error msg="Error running exec b484218100ebd8835e2265b8adbc63f24cefe72ebbeb7ad924416c550eb5969e in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:34 Czy dockerd[337]: time="2026-07-28T09:07:34.127541164+08:00" level=error msg="Error running exec 029185b96c0f6918c48b5c46d5c6ec5906a9c15bc692dafa8f78d36e496385f1 in container: exec attach failed: error attaching stdout stream: write unix /run/docker.sock->@: write: broken pipe"
Jul 28 09:07:36 Czy kernel: [ 1043.996863] ------------[ cut here ]------------
Jul 28 09:07:36 Czy kernel: [ 1043.998965] kernel BUG at fs/namei.c:844!
Jul 28 09:07:36 Czy kernel: [ 1043.999841] Oops: invalid opcode: 0000 [#1] SMP NOPTI
Jul 28 09:07:36 Czy kernel: [ 1044.000429] CPU: 7 UID: 0 PID: 13059 Comm: ls Not tainted 6.18.35.2-microsoft-standard-WSL2 #1 PREEMPT(none)
Jul 28 09:07:36 Czy kernel: [ 1044.001747] RIP: 0010:try_to_unlazy+0xbc/0xe0
Jul 28 09:07:36 Czy kernel: [ 1044.002640] Code: ff 84 c0 75 b8 81 63 38 ff fe ff ff 45 31 e4 48 c7 43 40 00 00 00 00 e8 32 bf d0 ff 44 89 e0 5b 41 5c 41 5d 5d c3 cc cc cc cc <0f> 0b 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 eb c8 0f 0b 66
Jul 28 09:07:36 Czy kernel: [ 1044.006124] RSP: 0018:ffffcec1a54d3ac0 EFLAGS: 00010246
Jul 28 09:07:36 Czy kernel: [ 1044.006538] RAX: 0000000000000004 RBX: ffffcec1a54d3b40 RCX: 0000000000000000
Jul 28 09:07:36 Czy kernel: [ 1044.007371] RDX: 0000000000000000 RSI: 000000000000002e RDI: ffffcec1a54d3b40
Jul 28 09:07:36 Czy kernel: [ 1044.008212] RBP: ffffcec1a54d3ad8 R08: 0000000000000064 R09: 0000000000003835
Jul 28 09:07:36 Czy kernel: [ 1044.009101] R10: 0000000000000002 R11: 00000002e4838045 R12: ffff88c8c97d4d80
Jul 28 09:07:36 Czy kernel: [ 1044.010116] R13: ffff88c8c97d4d80 R14: 0000000000000000 R15: ffffcec1a54d3c80
Jul 28 09:07:36 Czy kernel: [ 1044.011635] FS: 000072f8a06bd400(0000) GS:ffff88cad0186000(0000) knlGS:0000000000000000
Jul 28 09:07:36 Czy kernel: [ 1044.012606] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 28 09:07:36 Czy kernel: [ 1044.013214] CR2: 000072f8a0660060 CR3: 0000000135e41001 CR4: 0000000000b70ef0
Jul 28 09:07:36 Czy kernel: [ 1044.014043] Call Trace:
Jul 28 09:07:36 Czy kernel: [ 1044.014234]
Jul 28 09:07:36 Czy kernel: [ 1044.014456] complete_walk+0x43/0xb0
Jul 28 09:07:36 Czy kernel: [ 1044.015086] path_lookupat+0x9c/0x180
Jul 28 09:07:36 Czy kernel: [ 1044.015604] ? proc_pid_readlink+0x12d/0x1b0
Jul 28 09:07:36 Czy kernel: [ 1044.016224] filename_lookup+0xe2/0x1e0
Jul 28 09:07:36 Czy kernel: [ 1044.016538] ? do_readlinkat.part.0+0xa6/0x160
Jul 28 09:07:36 Czy kernel: [ 1044.017192] ? do_syscall_64+0x73/0x990
Jul 28 09:07:36 Czy kernel: [ 1044.017973] vfs_statx+0x69/0x100
Jul 28 09:07:36 Czy kernel: [ 1044.018429] do_statx+0x48/0x80
Jul 28 09:07:36 Czy kernel: [ 1044.018912] ? putname+0x63/0x80
Jul 28 09:07:36 Czy kernel: [ 1044.019289] ? __x64_sys_statx+0xb0/0xf0
Jul 28 09:07:36 Czy kernel: [ 1044.019607] ? __check_object_size+0x221/0x2c0
Jul 28 09:07:36 Czy kernel: [ 1044.019959] ? strncpy_from_user+0x2b/0x120
Jul 28 09:07:36 Czy kernel: [ 1044.020298] ? getname_flags.part.0+0x4b/0x1d0
Jul 28 09:07:36 Czy kernel: [ 1044.020709] ? getname_flags+0x3b/0x60
Jul 28 09:07:36 Czy kernel: [ 1044.021062] __x64_sys_statx+0xa6/0xf0
Jul 28 09:07:36 Czy kernel: [ 1044.021327] x64_sys_call+0x12a1/0x20f0
Jul 28 09:07:36 Czy kernel: [ 1044.021636] do_syscall_64+0x73/0x990
Jul 28 09:07:36 Czy kernel: [ 1044.022080] ? __x64_sys_statx+0xb0/0xf0
Jul 28 09:07:36 Czy kernel: [ 1044.022485] ? x64_sys_call+0x12a1/0x20f0
Jul 28 09:07:36 Czy kernel: [ 1044.022776] ? do_syscall_64+0x73/0x990
Jul 28 09:07:36 Czy kernel: [ 1044.023187] ? __x64_sys_readlink+0x29/0x40
Jul 28 09:07:36 Czy kernel: [ 1044.023504] ? x64_sys_call+0x1f7f/0x20f0
Jul 28 09:07:36 Czy kernel: [ 1044.023886] ? do_syscall_64+0x73/0x990
Jul 28 09:07:36 Czy kernel: [ 1044.024268] ? x64_sys_call+0x1f7f/0x20f0
Jul 28 09:07:36 Czy kernel: [ 1044.024600] ? do_syscall_64+0x73/0x990
Jul 28 09:07:36 Czy kernel: [ 1044.024954] ? irqentry_exit+0x3f/0x50
Jul 28 09:07:36 Czy kernel: [ 1044.025233] ? exc_page_fault+0x7f/0x170
Jul 28 09:07:36 Czy kernel: [ 1044.025591] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Jul 28 09:07:36 Czy kernel: [ 1044.026153] RIP: 0033:0x72f8a0868d4a
Jul 28 09:07:36 Czy kernel: [ 1044.026618] Code: b8 ff ff ff ff 64 c7 00 16 00 00 00 e9 95 fd ff ff e8 9a 08 02 00 66 2e 0f 1f 84 00 00 00 00 00 41 89 ca b8 4c 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2e 41 89 c1 85 c0 74 0f 48 8b 05 10 31 0e 00
Jul 28 09:07:36 Czy kernel: [ 1044.028017] RSP: 002b:00007ffcc12d2ce8 EFLAGS: 00000246 ORIG_RAX: 000000000000014c
Jul 28 09:07:36 Czy kernel: [ 1044.028818] RAX: ffffffffffffffda RBX: 000072f8a0660dc8 RCX: 000072f8a0868d4a
Jul 28 09:07:36 Czy kernel: [ 1044.029396] RDX: 0000000000000100 RSI: 00007ffcc12db3e5 RDI: 00000000ffffff9c
Jul 28 09:07:36 Czy kernel: [ 1044.030406] RBP: 000000000000025e R08: 00007ffcc12d2cf0 R09: 000072f8a094cbe0
Jul 28 09:07:36 Czy kernel: [ 1044.031063] R10: 000000000000025e R11: 0000000000000246 R12: 00007ffcc12db3e5
Jul 28 09:07:36 Czy kernel: [ 1044.031696] R13: 0000000000000000 R14: 00007ffcc12db3e5 R15: 000072f8a0660dc8
Jul 28 09:07:36 Czy kernel: [ 1044.032356]
Jul 28 09:07:36 Czy kernel: [ 1044.032639] Modules linked in: nf_conntrack_netlink xt_conntrack xt_MASQUERADE xfrm_user xfrm_algo xt_set ip_set xt_addrtype nft_compat autofs4 br_netfilter bridge stp llc ip_tables tun
Jul 28 09:07:36 Czy kernel: [ 1044.033855] ---[ end trace 0000000000000000 ]---
Jul 28 09:07:36 Czy kernel: [ 1044.034410] RIP: 0010:try_to_unlazy+0xbc/0xe0
Jul 28 09:07:36 Czy kernel: [ 1044.034766] Code: ff 84 c0 75 b8 81 63 38 ff fe ff ff 45 31 e4 48 c7 43 40 00 00 00 00 e8 32 bf d0 ff 44 89 e0 5b 41 5c 41 5d 5d c3 cc cc cc cc <0f> 0b 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 eb c8 0f 0b 66
Jul 28 09:07:36 Czy kernel: [ 1044.037417] RSP: 0018:ffffcec1a54d3ac0 EFLAGS: 00010246
Jul 28 09:07:36 Czy kernel: [ 1044.037883] RAX: 0000000000000004 RBX: ffffcec1a54d3b40 RCX: 0000000000000000
Jul 28 09:07:36 Czy kernel: [ 1044.038526] RDX: 0000000000000000 RSI: 000000000000002e RDI: ffffcec1a54d3b40
Jul 28 09:07:36 Czy kernel: [ 1044.039300] RBP: ffffcec1a54d3ad8 R08: 0000000000000064 R09: 0000000000003835
Jul 28 09:07:36 Czy kernel: [ 1044.039957] R10: 0000000000000002 R11: 00000002e4838045 R12: ffff88c8c97d4d80
Jul 28 09:07:36 Czy kernel: [ 1044.040543] R13: ffff88c8c97d4d80 R14: 0000000000000000 R15: ffffcec1a54d3c80
Jul 28 09:07:36 Czy kernel: [ 1044.041234] FS: 000072f8a06bd400(0000) GS:ffff88cad0186000(0000) knlGS:0000000000000000
Jul 28 09:07:36 Czy kernel: [ 1044.042344] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 28 09:07:36 Czy kernel: [ 1044.043141] CR2: 000072f8a0660060 CR3: 0000000135e41001 CR4: 0000000000b70ef0

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'.

In fact, WSL runs normally when installed using WSL_2.7.3.0.x64.msi or any earlier release. After upgrading to a newer version, however, it crashes spontaneously even when no operations are performed.

Mitchell Levy (@chessturo)

Have you seen this before Mitchell Levy (@chessturo) ?

Here's a comment for issue #41191:

Seeing an identical kernel BUG with a different configuration, which may help widen the repro conditions.

Environment (at time of crash):

WSL version: 2.7.11.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
Windows version: 10.0.26200.8973

Also reproduces after updating to WSL 2.9.4.0 / kernel 6.18.35.2-1 (same as OP).

Notably different from the original report:

networkingMode is NAT, not mirrored
dnsTunneling not enabled
Docker Desktop (WSL2 backend), not Docker Engine running natively
Project code lives inside the WSL filesystem (/workspace), not on /mnt/c
No buildx / cross-platform builds — ordinary VS Code dev containers under light load

So mirrored networking, DNS tunnelling, and 9P traffic to Windows-hosted files all appear to be unnecessary to trigger this.

Behaviour: the WSL VM disappears every ~1.5–3.5 hours. No shutdown or terminate events are logged on the Windows side, which makes it look like a silent VM loss until you capture an ETW trace.

From Microsoft.Windows.Lxss.Manager trace:

GuestCrash:
Kernel panic - not syncing: Fatal exception
RIP: 0010:try_to_unlazy+0xbc/0xe0
Call Trace:
complete_walk+0x43/0xb0
path_lookupat+0x9c/0x180
filename_lookup+0xe2/0x1e0
vfs_statx+0x69/0x100
do_statx+0x48/0x80
__x64_sys_statx+0xa6/0xf0
do_syscall_64+0x73/0x990

AbnormalVmExit:
{"ExitType":"UnexpectedExit",
"Attribution":[{"SystemExit":{"Detail":"UnexpectedExit","Initiator":"GuestOS"}},
{"WorkerExit":{"Type":"StoppedOnReset","Detail":"GuestCrash","Initiator":"GuestOS"}}]}

Same try_to_unlazy / statx path as the original report.

GuestCrash:
[ 4520.651846] RSP: 0018:ffffd397d0acbbb0 EFLAGS: 00010246
[ 4520.653869] CR2: 000075eaf6af80b8 CR3: 000000010ca21005 CR4: 0000000000b72ef0
Call Trace:

complete_walk+0x43/0xb0
path_lookupat+0x9c/0x180
filename_lookup+0xe2/0x1e0
? mod_memcg_lruvec_state+0xc6/0x1d0
? __lruvec_stat_mod_folio+0x8f/0xe0
? __folio_mod_stat+0x2c/0x90
vfs_statx+0x69/0x100
do_statx+0x48/0x80
? __check_object_size+0x221/0x2c0
? strncpy_from_user+0x2b/0x120
? getname_flags.part.0+0x4b/0x1d0
? getname_flags+0x3b/0x60
__x64_sys_statx+0xa6/0xf0
x64_sys_call+0x12a1/0x20f0
do_syscall_64+0x73/0x990
entry_SYSCALL_64_after_hwframe+0x76/0x7e

Modules linked in: tls nf_conntrack_netlink xt_conntrack xt_MASQUERADE xfrm_user
xfrm_algo xt_set ip_set xt_addrtype ip6t_REJECT nf_reject_ipv6 ipt_REJECT
nf_reject_ipv4 sunrpc nft_compat isofs btrfs blake2b_generic xor raid6_pq msdos
cfg80211 intel_rapl_msr intel_rapl_common kvm_intel kvm irqbypass sch_fq_codel
autofs4 br_netfilter bridge stp llc ip_tables tun
---[ end trace 0000000000000000 ]---
RIP: 0010:try_to_unlazy+0xbc/0xe0
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x23000000 from 0xffffffff81000000

AbnormalVmExit:
{"Status":-1070137082,"ExitType":"UnexpectedExit",
"Attribution":[{"SystemExit":{"Detail":"UnexpectedExit","Initiator":"GuestOS"}},
{"WorkerExit":{"Type":"StoppedOnReset","Detail":"GuestCrash","Initiator":"GuestOS"}},
{"GuestCrash":{"CrashParameters":[0,0,0,4297236480,3904]}}]}

TerminateVm: SystemId 81ac1dc3-b760-4189-89f4-0e8b6a7f1eca

colinrees

Third independent repro + root-cause analysis that reframes this away from 9P.

I hit this ~2×/day for a week and did a fair amount of forensics before pinning back to 2.7.3. Short version: the "9P dentry cache" framing is almost certainly a red herring — nameidata on the kernel stack is being corrupted, and VFS is just where the corruption gets caught.

Environment (widens the repro further)

WSL 2.7.10 / kernel 6.18.33.2-2. Multiple distros in one utility VM, VS Code Remote-WSL, tmux, heavy concurrent filesystem I/O.
Same Comm: ls, same RIP: try_to_unlazy+0xbc/0xe0, same statx → filename_lookup → path_lookupat → complete_walk trace as OP.
11 panics captured; all but one at try_to_unlazy+0xbc (the outlier was error_entry+0x0, "Fatal exception in interrupt").

Version boundary (matches OP & colinrees, adds an LTS data point)

WSL	Kernel	Result
2.7.10 / 2.7.9	6.18.33.2-2	panics ~2×/day
2.7.3	6.6.114.1-1	0 panics in weeks, identical workload

Every 6.18.x I ran panics; 6.6 LTS never trips it.

Why this isn't a VFS/9P bug — the assertion is architecturally unreachable

try_to_unlazy+0xbc is BUG_ON(!(nd->flags & LOOKUP_RCU)) at fs/namei.c:844 (verified against the shipped vmlinux: the __bug_table entry for fs/namei.c:844 resolves to that exact offset, and the panic's Code: bytes match the disassembly instruction-for-instruction).

But complete_walk() reads nd->flags, tests LOOKUP_RCU, writes it back, and calls try_to_unlazy() — which re-reads the same byte four instructions later, on the same CPU, on a task-local stack object. There is no legitimate control flow in which that bit clears in between. Upstream evidently agrees the check can't fire in production: it was removed in 7.0 — commit 729d015ab230 "fs: only assert on LOOKUP_RCU when built with CONFIG_DEBUG_VFS" (Mateusz Guzik), rationale "no use in production kernels." So OP's RAX=4 (LOOKUP_RCU clear where it must be set) is corruption, not a reachable state.

Conclusion: something is scribbling on the kernel stack — in the 6.18 line — and it's not the obvious suspects

I eliminated the two most likely out-of-tree culprits experimentally:

GPU / dxgkrnl — not it. [gpu] enabled=false in each distro + guiApplications=false (→ /dev/dxg gone, zero dxgkio traffic) → still panicked, 16 min after boot.
autoMemoryReclaim — not it. Removed from .wslconfig → still panicked.

Combined with colinrees's repro (NAT networking, no /mnt/c, no 9P, code in ext4 /workspace), the only common factor left is 6.18 kernel + concurrent path-lookup load — not 9P, not mirrored networking, not GPU, not memory reclaim.

Artifacts I can share if useful to Mitchell Levy (@chessturo)

WPR/ETW capture (Microsoft-Windows-Hyper-V-Compute → IVmGuestCrashEvents::OnGuestCrash) with the full guest panic text and Hyper-V's own attribution: "ExitType":"UnexpectedExit" … "Detail":"GuestCrash","Initiator":"GuestOS".
11 kernel-panic reports from %LocalAppData%\Temp\wsl-crashes\.

Happy to run a CONFIG_DEBUG_VFS/KASAN build or a targeted repro if that would help narrow the corruptor.

Anthony "Asterisk" Ambuehl (@asteriskSF)

Anthony "Asterisk" Ambuehl (@asteriskSF) Agreed on the fact the assert should be unreachable. If you (or anyone else who's able to repro this) are able and willing to run a custom kernel with KASAN on, that'd be great. Note that the current tip of WSL2-Linux-Kernel has a pretty hefty config diff from the kernel that's currently shipping with WSL, so it might be good to checkout and build the debug kernel on the linux-msft-wsl-6.18.35.2 tag.

Relatedly, if anyone who's seeing this issue is able to report their CPU model and microcode versions, that'd be great. I've previously seen some similar weird impossible bugs with shared stack traces caused by CPU hardware issues. Thanks!

Anthony "Asterisk" Ambuehl (@asteriskSF) Agreed on the fact the assert should be unreachable. If you (or anyone else who's able to repro this) are able and willing to run a custom kernel with KASAN on, that'd be great. Note that the current tip of WSL2-Linux-Kernel has a pretty hefty config diff from the kernel that's currently shipping with WSL, so it might be good to checkout and build the debug kernel on the linux-msft-wsl-6.18.35.2 tag.

Relatedly, if anyone who's seeing this issue is able to report their CPU model and microcode versions, that'd be great. I've previously seen some similar weird impossible bugs with shared stack traces caused by CPU hardware issues. Thanks!

Environment

Host OS: Windows 11
CPU: 13th Gen Intel(R) Core(TM) i9‑13980HX (Raptor‑Lake‑HX, Stepping B0, 8P+16E hybrid‑core)
WSL2 Kernel: 6.18.35.2‑microsoft‑standard‑WSL2 Will this be Open Source? #1 PREEMPT
Reproduction steps:
1. Launch WSL2, no heavy workload started.
2. Leave the instance idle since wsl start, no manual operations performed.
3. The kernel triggered a BUG panic automatically after a few minutes.

Crash log extracted from /var/log/syslog

root@Czy:/usr/code/12368-fayuan/cluster# tail -f /var/log/syslog
Aug 18 19:48:56 Czy systemd[860]: Starting wslg-session.service - WSLg user service...
Aug 18 19:48:56 Czy systemd[860]: Listening on dbus.socket - D-Bus User Message Bus Socket.
Aug 18 19:48:56 Czy systemd[860]: Reached target sockets.target - Sockets.
Aug 18 19:48:56 Czy systemd[860]: Reached target basic.target - Basic System.
Aug 18 19:48:56 Czy systemd[860]: Reached target default.target - Main User Target.
Aug 18 19:48:56 Czy systemd[1]: Started user@0.service - User Manager for UID 0.
Aug 18 19:48:56 Czy systemd[1]: Started session-1.scope - Session 1 of User root.
Aug 18 19:48:56 Czy systemd[860]: Finished wslg-session.service - WSLg user service.
Aug 18 19:48:56 Czy systemd[860]: Startup finished in 137ms.
Aug 18 19:49:32 Czy kernel: [ 48.347824] hv_balloon: Max. dynamic memory size: 16384 MB
Aug 18 20:03:55 Czy systemd[1]: Starting systemd-tmpfiles-clean.service - Cleanup of Temporary Directories...
Aug 18 20:03:55 Czy systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Aug 18 20:03:55 Czy systemd[1]: Finished systemd-tmpfiles-clean.service - Cleanup of Temporary Directories.
Aug 18 20:03:55 Czy systemd[1]: run-credentials-systemd\x2dtmpfiles\x2dclean.service.mount: Deactivated successfully.
Aug 18 20:15:07 Czy kernel: [ 1583.773597] ------------[ cut here ]------------
Aug 18 20:15:07 Czy kernel: [ 1583.775759] kernel BUG at fs/namei.c:844!
Aug 18 20:15:07 Czy kernel: [ 1583.776403] Oops: invalid opcode: 0000 [#1] SMP NOPTI
Aug 18 20:15:07 Czy kernel: [ 1583.777086] CPU: 0 UID: 0 PID: 17620 Comm: ls Not tainted 6.18.35.2-microsoft-standard-WSL2 #1 PREEMPT(none)
Aug 18 20:15:07 Czy kernel: [ 1583.777787] RIP: 0010:try_to_unlazy+0xbc/0xe0
Aug 18 20:15:07 Czy kernel: [ 1583.778119] Code: ff 84 c0 75 b8 81 63 38 ff fe ff ff 45 31 e4 48 c7 43 40 00 00 00 00 e8 32 bf d0 ff 44 89 e0 5b 41 5c 41 5d 5d c3 cc cc cc cc <0f> 0b 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 eb c8 0f 0b 66
Aug 18 20:15:07 Czy kernel: [ 1583.779288] RSP: 0018:ffffcc51e7417820 EFLAGS: 00010246
Aug 18 20:15:07 Czy kernel: [ 1583.779754] RAX: 0000000000000000 RBX: ffffcc51e74178a0 RCX: 0000000000000000
Aug 18 20:15:07 Czy kernel: [ 1583.780266] RDX: 0000000000000000 RSI: 0000000000000029 RDI: ffffcc51e74178a0
Aug 18 20:15:07 Czy kernel: [ 1583.780755] RBP: ffffcc51e7417838 R08: 0000000000000064 R09: 0000000000000031
Aug 18 20:15:07 Czy kernel: [ 1583.781261] R10: 0000000000000002 R11: 00000001e8c194ed R12: ffff8a350367fc00
Aug 18 20:15:07 Czy kernel: [ 1583.781872] R13: ffff8a350367fc00 R14: 0000000000000000 R15: ffffcc51e74179e0
Aug 18 20:15:07 Czy kernel: [ 1583.782387] FS: 00007476aada6800(0000) GS:ffff8a3854fc6000(0000) knlGS:0000000000000000
Aug 18 20:15:07 Czy kernel: [ 1583.783266] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 18 20:15:07 Czy kernel: [ 1583.784043] CR2: 00007476aad650b8 CR3: 00000002eb84a006 CR4: 0000000000b70ef0
Aug 18 20:15:07 Czy kernel: [ 1583.785634] Call Trace:
Aug 18 20:15:07 Czy kernel: [ 1583.785976]
Aug 18 20:15:07 Czy kernel: [ 1583.786229] complete_walk+0x43/0xb0
Aug 18 20:15:07 Czy kernel: [ 1583.786493] path_lookupat+0x9c/0x180
Aug 18 20:15:07 Czy kernel: [ 1583.786764] filename_lookup+0xe2/0x1e0
Aug 18 20:15:07 Czy kernel: [ 1583.787145] ? filename_lookup+0xe2/0x1e0
Aug 18 20:15:07 Czy kernel: [ 1583.787394] ? avc_has_perm_noaudit+0x72/0xf0
Aug 18 20:15:07 Czy kernel: [ 1583.787904] ? from_kgid_munged+0x1b/0x30
Aug 18 20:15:07 Czy kernel: [ 1583.788328] vfs_statx+0x69/0x100
Aug 18 20:15:07 Czy kernel: [ 1583.788601] do_statx+0x48/0x80
Aug 18 20:15:07 Czy kernel: [ 1583.788842] ? __check_object_size+0x221/0x2c0
Aug 18 20:15:07 Czy kernel: [ 1583.789182] ? strncpy_from_user+0x2b/0x120
Aug 18 20:15:07 Czy kernel: [ 1583.789438] ? getname_flags.part.0+0x4b/0x1d0
Aug 18 20:15:07 Czy kernel: [ 1583.790008] ? getname_flags+0x3b/0x60
Aug 18 20:15:07 Czy kernel: [ 1583.790254] __x64_sys_statx+0xa6/0xf0
Aug 18 20:15:07 Czy kernel: [ 1583.790500] x64_sys_call+0x12a1/0x20f0
Aug 18 20:15:07 Czy kernel: [ 1583.790753] do_syscall_64+0x73/0x990
Aug 18 20:15:07 Czy kernel: [ 1583.791037] ? dynamic_dname+0x8e/0xc0
Aug 18 20:15:07 Czy kernel: [ 1583.791385] ? selinux_ptrace_access_check+0x9b/0xb0
Aug 18 20:15:07 Czy kernel: [ 1583.791946] ? mntput_no_expire+0x50/0x2a0
Aug 18 20:15:07 Czy kernel: [ 1583.792213] ? mntput+0x28/0x40
Aug 18 20:15:07 Czy kernel: [ 1583.792447] ? path_put+0x22/0x30
Aug 18 20:15:07 Czy kernel: [ 1583.792706] ? proc_pid_readlink+0x12d/0x1b0
Aug 18 20:15:07 Czy kernel: [ 1583.793231] ? mntput_no_expire+0x50/0x2a0
Aug 18 20:15:07 Czy kernel: [ 1583.793569] ? putname+0x63/0x80
Aug 18 20:15:07 Czy kernel: [ 1583.793922] ? do_readlinkat.part.0+0xa6/0x160
Aug 18 20:15:07 Czy kernel: [ 1583.794472] ? __x64_sys_readlink+0x29/0x40
Aug 18 20:15:07 Czy kernel: [ 1583.794809] ? x64_sys_call+0x1f7f/0x20f0
Aug 18 20:15:07 Czy kernel: [ 1583.795186] ? do_syscall_64+0x73/0x990
Aug 18 20:15:07 Czy kernel: [ 1583.795554] ? __x64_sys_statx+0xb0/0xf0
Aug 18 20:15:07 Czy kernel: [ 1583.795903] ? x64_sys_call+0x12a1/0x20f0
Aug 18 20:15:07 Czy kernel: [ 1583.796205] ? do_syscall_64+0x73/0x990
Aug 18 20:15:07 Czy kernel: [ 1583.796590] ? handle_mm_fault+0xc3/0x2c0
Aug 18 20:15:07 Czy kernel: [ 1583.796947] ? do_user_addr_fault+0x179/0x710
Aug 18 20:15:07 Czy kernel: [ 1583.797478] ? irqentry_exit+0x3f/0x50
Aug 18 20:15:07 Czy kernel: [ 1583.797887] ? exc_page_fault+0x7f/0x170
Aug 18 20:15:07 Czy kernel: [ 1583.798158] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Aug 18 20:15:07 Czy kernel: [ 1583.798592] RIP: 0033:0x7476aaf3ab3a
Aug 18 20:15:07 Czy kernel: [ 1583.798916] Code: 48 8b 05 c9 b2 0d 00 ba ff ff ff ff 64 c7 00 16 00 00 00 e9 a5 fd ff ff e8 b3 06 02 00 0f 1f 00 41 89 ca b8 4c 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2e 89 c1 85 c0 74 0f 48 8b 05 91 b2 0d 00 64
Aug 18 20:15:07 Czy kernel: [ 1583.800697] RSP: 002b:00007ffc7fcee578 EFLAGS: 00000246 ORIG_RAX: 000000000000014c
Aug 18 20:15:07 Czy kernel: [ 1583.801551] RAX: ffffffffffffffda RBX: 00007476aad651a8 RCX: 00007476aaf3ab3a
Aug 18 20:15:07 Czy kernel: [ 1583.802052] RDX: 0000000000000900 RSI: 00007ffc7fcf619f RDI: 00000000ffffff9c
Aug 18 20:15:07 Czy kernel: [ 1583.802644] RBP: 000000000000025e R08: 00007ffc7fcee580 R09: 00005e489fa6b4c0
Aug 18 20:15:07 Czy kernel: [ 1583.803174] R10: 000000000000025e R11: 0000000000000246 R12: 00007ffc7fcf619f
Aug 18 20:15:07 Czy kernel: [ 1583.803747] R13: 0000000000000000 R14: 00007476aad65190 R15: 0000000000000001
Aug 18 20:15:07 Czy kernel: [ 1583.804372]
Aug 18 20:15:07 Czy kernel: [ 1583.804534] Modules linked in: nf_conntrack_netlink xt_conntrack xt_MASQUERADE xfrm_user xfrm_algo xt_set ip_set xt_addrtype nft_compat autofs4 br_netfilter bridge stp llc ip_tables tun
Aug 18 20:15:07 Czy kernel: [ 1583.805720] ---[ end trace 0000000000000000 ]---
Aug 18 20:15:07 Czy kernel: [ 1583.806585] RIP: 0010:try_to_unlazy+0xbc/0xe0
Aug 18 20:15:07 Czy kernel: [ 1583.806942] Code: ff 84 c0 75 b8 81 63 38 ff fe ff ff 45 31 e4 48 c7 43 40 00 00 00 00 e8 32 bf d0 ff 44 89 e0 5b 41 5c 41 5d 5d c3 cc cc cc cc <0f> 0b 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 eb c8 0f 0b 66
Aug 18 20:15:07 Czy kernel: [ 1583.808341] RSP: 0018:ffffcc51e7417820 EFLAGS: 00010246
Aug 18 20:15:07 Czy kernel: [ 1583.808700] RAX: 0000000000000000 RBX: ffffcc51e74178a0 RCX: 0000000000000000
Aug 18 20:15:07 Czy kernel: [ 1583.809286] RDX: 0000000000000000 RSI: 0000000000000029 RDI: ffffcc51e74178a0
Aug 18 20:15:07 Czy kernel: [ 1583.809866] RBP: ffffcc51e7417838 R08: 0000000000000064 R09: 0000000000000031
Aug 18 20:15:07 Czy kernel: [ 1583.810601] R10: 0000000000000002 R11: 00000001e8c194ed R12: ffff8a350367fc00
Aug 18 20:15:07 Czy kernel: [ 1583.811371] R13: ffff8a350367fc00 R14: 0000000000000000 R15: ffffcc51e74179e0

My own experiences, with help from Claude...

CPU INFO (13950hx 13th gen)

Reproduction: `try_to_unlazy` panic via three different syscalls

Reproduced this independently on Win 11 (Windows 10.0.26200.9168), WSL 2.7.12.0, kernel 6.18.33.2-microsoft-standard-WSL2, via debugConsole=true. Not tied to one tool -- hit it via VS Code Remote-WSL file-stat load, and separately via a plain wsl --import (no VS Code/Docker involved at all). Three different syscalls hit the identical complete_walk -> try_to_unlazy BUG at fs/namei.c:844.

1. bsdtar doing mkdir during wsl --import:

[  373.343353] ------------[ cut here ]------------
[  373.344278] kernel BUG at fs/namei.c:844!
[  373.345276] CPU: 0 UID: 0 PID: 147 Comm: bsdtar Not tainted 6.18.33.2-microsoft-standard-WSL2 #1 PREEMPT(none)
[  373.346642] RIP: 0010:try_to_unlazy+0xbc/0xe0
[  373.357725]  <TASK>
[  373.358405]  complete_walk+0x43/0xb0
[  373.359418]  path_parentat+0x49/0x70
[  373.359977]  __filename_parentat+0xf7/0x220
[  373.362940]  filename_create+0x46/0x150
[  373.365074]  do_mkdirat+0x4c/0x180
[  373.365584]  __x64_sys_mkdir+0x4d/0x70
[  373.366133]  x64_sys_call+0x1c04/0x20f0
[  373.366888]  do_syscall_64+0x73/0x990
[  373.394674] Kernel panic - not syncing: Fatal exception

2. ls via statx:

[   91.080661] ------------[ cut here ]------------
[   91.082570] kernel BUG at fs/namei.c:844!
[   91.085262] CPU: 24 UID: 1000 PID: 2589 Comm: ls Not tainted 6.18.33.2-microsoft-standard-WSL2 #1 PREEMPT(none)
[   91.097477] RIP: 0010:try_to_unlazy+0xbc/0xe0
[   91.130102]  <TASK>
[   91.133933]  complete_walk+0x43/0xb0
[   91.134753]  path_lookupat+0x9c/0x180
[   91.135533]  filename_lookup+0xe2/0x1e0
[   91.138832]  vfs_statx+0x69/0x100
[   91.139592]  do_statx+0x48/0x80
[   91.145634]  __x64_sys_statx+0xa6/0xf0
[   91.147478]  do_syscall_64+0x73/0x990
[   91.193321] Kernel panic - not syncing: Fatal exception

3. ls via llistxattr, ~20 min after a non-fatal RCU warning in the same boot:

[   87.430155] ------------[ cut here ]------------
[   87.432067] WARNING: CPU: 5 PID: 1500 at kernel/rcu/tree_plugin.h:826 rcu_sched_clock_irq+0x953/0x12c0
[   87.434964] CPU: 5 UID: 1000 PID: 1500 Comm: ls Not tainted 6.18.33.2-microsoft-standard-WSL2 #1 PREEMPT(none)
[   87.453590]  hv_stimer0_isr+0x24/0x30
[   87.453802]  __sysvec_hyperv_stimer0+0x36/0x60
[   87.454289]  sysvec_hyperv_stimer0+0x3e/0xa0

[ 1127.557584] ------------[ cut here ]------------
[ 1127.558541] kernel BUG at fs/namei.c:844!
[ 1127.559358] CPU: 26 UID: 1000 PID: 19338 Comm: ls Tainted: G        W           6.18.33.2-microsoft-standard-WSL2 #1 PREEMPT(none)
[ 1127.560530] RIP: 0010:try_to_unlazy+0xbc/0xe0
[ 1127.566669]  <TASK>
[ 1127.566794]  complete_walk+0x43/0xb0
[ 1127.566919]  path_lookupat+0x9c/0x180
[ 1127.567050]  filename_lookup+0xe2/0x1e0
[ 1127.567497]  path_listxattrat+0x7b/0x180
[ 1127.567626]  __x64_sys_llistxattr+0x28/0x30
[ 1127.587005] Kernel panic - not syncing: Fatal exception

Each panic takes down the whole VM mid-syscall, which caused real downstream damage here: EXT4 corruption on the guest root disk (needed e2fsck -fy from a second distro to repair) and git ref corruption (two refs zeroed to 0000...0000, from a ref file truncated mid-write).

Separately, also saw a milder, non-fatal failure on the same kernel -- a 9P channel disruption (Exception: Operation canceled @p9io.cpp:258 (AcceptAsync)) that makes WSL's own init exit and the VM quietly restart, with nothing logged in any Hyper-V event provider. Not sure if it shares a root cause with the panic above; noting in case it's useful.

Workaround: downgrading the WSL app to 2.6.1.0 (kernel 6.6.87.2-1, pre-6.18) avoids the panic (older I know, but other team members that had not updated WSL were using that successfully, so I reverted to it to match their env). Testing over past 15 hours indicates a rock-solid env again.
.wslconfig tuning (guiApplications=false, reduced processors=) did not reliably help; crash intervals varied 27s-19min regardless, looking like a stochastic race rather than something config-controllable.

For me i think the issue was caused by the intel CPU degradation bug.. Got Intel to replace the CPU and the issue has gone.

CPU/microcode data point as requested: Intel i9-14900HX (Raptor Lake-HX, CPUID 06-b7-01), microcode 0x11F, built 2023-09-06 — notably ancient. The OEM (MSI Raider 18 HX A14VGG) never shipped a BIOS with newer microcode, and client Windows's mcupdate_GenuineIntel.dll contains no 06-b7 entries at all, so the 9 later official revisions (0x122→0x137, including the 0x12B/0x12F Raptor Lake stability updates) are all absent on this machine. cpumcupdate event 40 "Failed to update microcode on one or more CPUs" logs on every boot.

Hit this panic 4× on 6.18.33.2 (statx path, Comm: ls), plus one error_entry panic (Comm: python3.12); never on 6.6.87.2 over ~7 weeks of daily use — consistent with the 6.18-only observation above. The same machine also reproduces the __vma_start_write D-state deadlock of #41113 within 15 s – 2 min; detailed environment and a reproducer are posted there: #41113 (comment)

I encountered the same try_to_unlazy kernel panic, but under a substantially different environment and without the reported 9P/restart sequence.

Environment:

Windows: 10.0.26200.9457
WSL: 2.7.14.0
Kernel: 6.18.33.2-2
Distribution: Ubuntu 24.04
Networking: NAT
dnsTunneling=false
Docker Desktop using WSL integration
No native Docker Engine or cross-platform BuildKit workload inside the distribution

At 2026-09-14 21:10:15 PDT, WSL generated a kernel-panic report with:

RIP: 0010:try_to_unlazy+0xbc/0xe0

Call Trace:
 complete_walk+0x43/0xb0
 path_lookupat+0x9c/0x180
 filename_lookup+0xe2/0x1e0
 vfs_statx+0x69/0x100
 do_statx+0x48/0x80
 __x64_sys_statx+0xa6/0xf0
 x64_sys_call+0x12a1/0x20f0
 do_syscall_64+0x73/0x990
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Kernel panic - not syncing: Fatal exception

The instruction bytes and call chain closely match this issue. One difference is that my captured state contains RAX=0, whereas the original report contains RAX=4.

The distribution had been running for approximately 30 hours (108929 seconds of kernel uptime). The journal ended abruptly without a preceding clean shutdown, Linux OOM event, filesystem I/O error, or visible 9P/virtiofs channel disruption.

An external Windows monitor provides this timeline:

21:10:08  Ubuntu and docker-desktop running; original boot ID
21:10:15  kernel panic and Hyper-V VM unexpected-exit event
21:10:17  HNS guest networking degraded/destroyed
21:10:20  replacement WSL VM started
21:10:33  Ubuntu running with a new boot ID; docker-desktop distro not running

Hyper-V Compute reported error 0xC0370106 for the original VM at the exact panic timestamp. Docker Desktop’s WSL proxy then failed because its pipe to the distribution was closed. Docker API /stats?stream=false requests immediately before the panic completed normally.

This appears to confirm that:

The issue also affects kernel 6.18.33.2-2.
It occurs with Docker Desktop WSL integration, not only native Docker/BuildKit.
NAT networking is also affected.
A preceding WSL restart or observable 9P channel disruption may not be required.
Docker and Remote-WSL failures are downstream consequences of the kernel panic.

I provided the complete kernel-panic report and Microsoft WSL diagnostic package if useful.

WSL-kernel-panic-try_to_unlazy-20260914.txt

Anthony "Asterisk" Ambuehl (@asteriskSF)

I've being getting frequent crashes with WSL but I only got the past 3 panics that happened in the last four days and all seems related to this issue. All at try_to_unlazy+0xbc/0xe0, identical Code: bytes, ending Kernel panic - not syncing: Fatal exception.

When (UTC-3)	Guest uptime	Syscall
2026-09-19 13:08:34	345640 s (~4 d)	`readlink`
2026-09-21 21:38:45	36120 s (~10 h)	`statx`
2026-09-22 13:20:49	56516 s (~15.7 h)	`statx`

But I've got a new readlink syscall besides statx. Which I think further supports Anthony "Asterisk" Ambuehl (@asteriskSF)'s reading that nameidata is being scribbled on rather than anything statx-specific, as this goes through do_readlinkat instead:

[345640.329028] Tainted: [W]=WARN
[345640.329737] RIP: 0010:try_to_unlazy+0xbc/0xe0
[345640.333417] RAX: 0000000000000008 RBX: ffffcf8d2ca3fd40 RCX: 0000000000000000
[345640.338986] Call Trace:
[345640.339462]  complete_walk+0x43/0xb0
[345640.339783]  path_lookupat+0x9c/0x180
[345640.340093]  ? prepend_path+0x22e/0x300
[345640.340503]  filename_lookup+0xe2/0x1e0
[345640.341497]  do_readlinkat.part.0+0x60/0x160
[345640.341892]  __x64_sys_readlink+0x29/0x40
[345640.342405]  do_syscall_64+0x73/0x990
[345640.343381]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[345640.358659] Kernel panic - not syncing: Fatal exception

OP has RAX=4, warlockhouseefs has RAX=0. I've got RAX=8 (the readlink panic) and RAX=0 (both statx panics) all with LOOKUP_RCU clear where it must be set.
The 2026-09-21 panic came through proc_pid_readlink (/proc/<pid>/…), which never touches DrvFs, and there was no preceding WSL restart or unclean shutdown in any of the three.
Since no WSL diagnostic package was being captured at panic time, I can't confirm or rule out a p9io.cpp:258 precursor.

CPU / microcode


CPU	Intel i9-14900K , CPUID 06-B7-01 (Family 6 Model 183 Stepping 1)
Microcode	0x12F (included by BIOS, not late-patched by Windows)
Board / BIOS	Gigabyte Z790 UD AX, AMI F17, 2026-06-11

I'm on 0x12F on a recent BIOS, my CPU has never been RMA'd (it could be degraded). So current microcode seems unable to help.

Environment

Windows 10.0.26200.9457
WSL 2.7.8.0
Kernel 6.18.33.1-1
Ubuntu 24.04.4 LTS (plus the docker-desktop distro; Docker Desktop 4.82.0 via WSL integration (no native engine, no BuildKit cross-builds)
networkingMode=mirrored, autoMemoryReclaim=gradual, swap=0, memory=51GiB
/mnt/c is plan9 over hvsocket (trans=fd, msize=65536) (no virtiofs)
A PPP VPN was up (ppp_async/ppp_deflate/bsd_comp in the module list)

kernel-panic-1789834114-{0e792200-0b07-4c57-9b2f-48e49167a739}.txt
kernel-panic-1790037525-{97753361-9ff1-4713-bb7d-ed2de88f12ff}.txt
kernel-panic-1790094049-{ac1fd281-f8be-4794-b1eb-179eceee8736}.txt

Another data point: two panics with this signature on one machine, 400 seconds apart, on 6.18.33.2-2. Posting the hardware details asked for above.

Environment

WSL 2.7.11.0, kernel 6.18.33.2-2 (6.18.33.2-microsoft-standard-WSL2, PREEMPT(none)), WSLg 1.0.73.2
Windows 10.0.26200.9278
Distro: Ubuntu 26.04, systemd enabled; no networkingMode is set; .wslconfig holds only memory=16GB and instanceIdleTimeout=600000
CPU: Intel Core i7-14700F (family 6, model 183, stepping 1)
Board: ASUS TUF GAMING Z790-PLUS WIFI, BIOS 1641 (February 2024)
Microcode revision in force: 0x123 (registry Update Revision and Previous Update Revision both 23 01 00 00), so older than 0x125, 0x129, 0x12B and 0x12F. A BIOS update to the vendor's current release is planned.

What happened

Both dumps are from %LOCALAPPDATA%\Temp\wsl-crashes, 2026-10-12. The workload is many short-lived processes, each started in its own mount and PID namespace (bubblewrap, about fifty bind mounts over single files and directories of one ext4 tree). Docker Engine is installed in the distro and Docker Desktop on Windows; the commands of this workload did not use either.

First panic at kernel uptime 4676 s, a few seconds after an 18-process pytest run was launched. Only the tail of the oops was kept (no header). openat (abridged: the ? frames are dropped):

RIP: 0010:try_to_unlazy+0xbc/0xe0
RAX: 0000000000000000 RBX: ffffd07a89a67c90 RCX: 0000000000000000
Call Trace:
 <TASK>
 complete_walk+0x43/0xb0
 path_lookupat+0x9c/0x180
 ? alloc_empty_file+0x7f/0x130
 path_openat+0x838/0x1310
 do_filp_open+0xc3/0x170
 do_sys_openat2+0x71/0xd0
 __x64_sys_openat+0x58/0xa0
 x64_sys_call+0x147b/0x20f0
 do_syscall_64+0x73/0x990
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Kernel panic - not syncing: Fatal exception

Second panic 385 s after the VM came back, the last command on record before it being a finished git log. lstat from a Python process (abridged: Code:, segment registers, ? frames and the user-side registers are dropped):

kernel BUG at fs/namei.c:844!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 14 UID: 1000 PID: 2983 Comm: python Tainted: G        W           6.18.33.2-microsoft-standard-WSL2 #1 PREEMPT(none)
Tainted: [W]=WARN
RIP: 0010:try_to_unlazy+0xbc/0xe0
RSP: 0018:ffffd3280d4f7bc0 EFLAGS: 00010246
RAX: 0000000000000001 RBX: ffffd3280d4f7c40 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffd3280d4f7c40
RBP: ffffd3280d4f7bd8 R08: 0000000000000100 R09: 00006c61636f6c2e
R10: 0000000000000002 R11: 000000067e794dd3 R12: ffff8cc40a33f080
R13: ffff8cc40a33f080 R14: 0000000000000000 R15: ffffd3280d4f7d88
Call Trace:
 <TASK>
 complete_walk+0x43/0xb0
 path_lookupat+0x9c/0x180
 filename_lookup+0xe2/0x1e0
 vfs_statx+0x69/0x100
 __do_sys_newlstat+0x4a/0xa0
 ? __seccomp_filter+0x39/0x5c0
 __x64_sys_newlstat+0x1a/0x20
 x64_sys_call+0x1e14/0x20f0
 do_syscall_64+0x73/0x990
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Modules linked in: 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 sch_fq_codel autofs4 br_netfilter bridge stp llc ip_tables tun
Kernel panic - not syncing: Fatal exception

RAX at the trap is 0 in the first and 1 in the second. The kernel log of both boots is gone, so I cannot say what preceded either.

Also on this machine

A stall with the symptoms of #41113: on 2026-10-10, four times in about twenty-five starts of the same 18-process pytest pool, one worker froze in state D in __vma_start_write (anonymous mmap three times, brk once) while still starting up, with SIGKILL pending and never delivered. wsl --terminate of the distro did not clear the tasks.

The full dump files can be attached if they help.

WSL 3.0.5 kernel 6.18.58.1 repeatedly panics, disconnecting VS Code

WSL 2 repeatedly terminates and causes VS Code Remote to show “Reconnecting to WSL.”

This is not memory exhaustion. At failure, WSL had approximately 29 GiB available and no swap usage.

WSL created a kernel-panic dump showing:

Oops: invalid opcode
RIP: try_to_unlazy+0xbc/0xe0
complete_walk
path_lookupat
filename_lookup
do_readlinkat
Kernel panic - not syncing: Fatal exception

Environment

WSL: 3.0.5.0
Kernel: 6.18.58.1-1
Windows: 10.0.26300.9711
Distribution: Ubuntu 24.04, WSL 2
CPU: Intel Core i9-14900K
BIOS: Lenovo S0IKT72A, 2024-12-24

Navigation Menu

Repository navigation

Kernel BUG at fs/namei.c:844 (try_to_unlazy) after 9P/virtiofs channel disruption causes WSL2 crash #41191

Windows Version

WSL Version

Are you using WSL 1 or WSL 2?

Kernel Version

Distro Version

Other Software

Repro Steps

Expected Behavior

Actual Behavior

Diagnostic Logs

Logs are required for review from WSL team

Environment (widens the repro further)

Version boundary (matches OP & colinrees, adds an LTS data point)

Why this isn't a VFS/9P bug — the assertion is architecturally unreachable

Conclusion: something is scribbling on the kernel stack — in the 6.18 line — and it's not the obvious suspects

Artifacts I can share if useful to Mitchell Levy (@chessturo)

Environment

Crash log extracted from /var/log/syslog

Reproduction: `try_to_unlazy` panic via three different syscalls

CPU / microcode

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Kernel BUG at fs/namei.c:844 (try_to_unlazy) after 9P/virtiofs channel disruption causes WSL2 crash #41191

Description

Windows Version

WSL Version

Are you using WSL 1 or WSL 2?

Kernel Version

Distro Version

Other Software

Repro Steps

Expected Behavior

Actual Behavior

Diagnostic Logs

Activity

github-actions commented on Jul 28, 2026

Logs are required for review from WSL team

poriscui commented on Jul 28, 2026

OneBlue commented on Jul 28, 2026

colinrees commented on Aug 2, 2026

asteriskSF commented on Aug 10, 2026

Environment (widens the repro further)

Version boundary (matches OP & colinrees, adds an LTS data point)

Why this isn't a VFS/9P bug — the assertion is architecturally unreachable

Conclusion: something is scribbling on the kernel stack — in the 6.18 line — and it's not the obvious suspects

Artifacts I can share if useful to Mitchell Levy (@chessturo)

chessturo commented on Aug 17, 2026

poriscui commented on Aug 18, 2026

Environment

Crash log extracted from /var/log/syslog

KarlBlomquist commented on Aug 25, 2026

Reproduction: try_to_unlazy panic via three different syscalls

colinrees commented on Aug 25, 2026

Nijat816 commented on Aug 26, 2026

warlockhouseefs commented on Sep 17, 2026

hlouzada commented on Sep 22, 2026

CPU / microcode

Environment

seasonmsg commented on Oct 12, 2026

kxs-mamin commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Reproduction: `try_to_unlazy` panic via three different syscalls