The Linux Kernel Microsoft Actually Maintains for WSL2

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.

Checking your actual running kernel version directly

uname -r

reports the actual kernel version currently running, which you can compare against the current release listed in Microsoft’s own microsoft/WSL2-Linux-Kernel repository to confirm whether you’re on a current build or meaningfully behind. This is a genuinely more reliable check than assuming a recent Windows update implies a recent kernel, given the two now update independently.

Forcing a kernel update explicitly

wsl --update

This checks for and applies an available WSL platform update, including a newer kernel build if one is available, independent of Windows Update’s own schedule. Running this explicitly, rather than assuming kernel updates happen automatically on the same cadence as other software, matters specifically when troubleshooting a kernel-level bug that a newer build is documented to fix.

Why running an unofficial or third-party kernel is a real, if sometimes justified, departure

Some users build and run a fully custom kernel rather than Microsoft’s maintained build, typically to enable a specific module or feature the stock configuration excludes. Doing so means explicitly taking over responsibility for that kernel’s own security patching and updates going forward — Microsoft’s regular kernel update channel no longer applies to a machine pointed at a custom-built kernel image, which is a genuine, ongoing maintenance commitment rather than a one-time build-and-forget action.

Why the kernel source being public actually matters in practice

Auditability isn’t just a nice-to-have property here — it directly affects how quickly and confidently the community and security researchers can evaluate WSL2’s kernel against known upstream Linux vulnerabilities. Because the WSL2 kernel is a documented fork of a specific upstream Linux version with a visible patch set on top, tracking whether a given CVE affecting mainline Linux also affects the WSL2 kernel fork is a matter of checking the fork’s actual source and patch history, rather than trusting an opaque vendor statement with no way to independently verify it.

The relationship between kernel updates and distro package updates, made concrete

A distribution’s own package manager and the WSL2 kernel are genuinely separate update surfaces, and conflating them leads to real confusion during troubleshooting. Running apt full-upgrade inside Ubuntu updates Ubuntu’s own packages — including, confusingly, a kernel package that Ubuntu ships for compatibility reasons, but which isn’t the kernel actually running under WSL2 at all, since that’s supplied by the WSL platform layer instead. A user troubleshooting a kernel-related issue who only runs distro package updates, without separately running wsl --update, may never actually touch the kernel that’s the real source of their problem — recognizing these as two entirely separate update paths is essential before concluding a specific fix “didn’t work.”

Reporting a genuine kernel-level bug

Because the kernel source is public, a suspected kernel-level bug (rather than an application or distro-package issue) can be checked against and reported directly to the microsoft/WSL2-Linux-Kernel or microsoft/WSL GitHub repositories, with the specific kernel version (from uname -r) and reproduction steps — considerably more actionable for the maintainers than a report describing symptoms without that specific version information, given how directly tied kernel behavior is to the exact build in use.

Related:

Sources: