The Linux Kernel Microsoft Actually Maintains for WSL2
WSL2 doesn't borrow a distro's kernel — Microsoft maintains its own fork, patched specifically for the virtualized environment WSL2 runs in, and ships it independently of both Windows and any Linux distro's own kernel.
WSL2 runs a genuine Linux kernel, not a translation layer — but it’s specifically Microsoft’s own maintained fork of the Linux kernel, not the kernel bundled with whatever distro you’re running inside WSL, and understanding that distinction clarifies a lot about how WSL2 actually gets updated.
Why WSL2 needs its own kernel fork at all
A distro’s own kernel package is generally built assuming it’s running on physical hardware or a general-purpose hypervisor — WSL2’s kernel needs specific patches for its particular lightweight virtual machine environment: tight integration with the Windows host for things like the 9P-based filesystem bridge and networking passthrough that a stock distro kernel wouldn’t include by default.
Where Microsoft’s kernel source actually lives
Microsoft maintains this kernel fork as an open-source project on GitHub (microsoft/WSL2-Linux-Kernel), based on the upstream Linux kernel with WSL2-specific patches layered on top — meaning the kernel’s source is publicly auditable, not a closed, undocumented modification.
How the kernel actually gets updated on your machine
The WSL2 kernel updates independently of your Linux distro’s own package manager — running apt upgrade inside an Ubuntu WSL distro updates userland packages, not the underlying kernel. The kernel itself updates through Windows Update or, since WSL moved to being distributed as a Microsoft Store app, through the Store’s own update mechanism.
Why every WSL2 distro shares the same kernel
Because the kernel lives at the WSL2 platform level rather than inside any individual distro instance, every distro you run under WSL2 — Ubuntu, Debian, Fedora, whatever else — shares the exact same underlying kernel version at any given time. This is architecturally different from running multiple separate virtual machines, each of which could run its own independently-versioned kernel.
What this means practically when troubleshooting
If you hit a kernel-level issue (a missing kernel module, a specific /proc or /sys behavior that doesn’t match bare-metal Linux), updating your distro’s own packages won’t fix it — you need wsl --update to pull a newer kernel build, since the kernel and the distro userland are updated through entirely separate mechanisms.
Why this architecture choice actually makes sense
Centralizing kernel maintenance at the WSL2 platform level, rather than trusting each distro’s own kernel package to work correctly in a Microsoft-specific virtualized environment, lets Microsoft ship kernel-level WSL2 improvements (better filesystem performance, GPU passthrough support, improved memory reclaim) uniformly across every distro at once, rather than depending on each individual distro maintainer to separately patch and test their own kernel package for WSL2 compatibility.