Why Can't Your WSL Ubuntu Use the Latest Linux Kernel? A Deep Dive into Microsoft’s Kernel Strategy

Current WSL kernel

As of July 2026 the publicly released WSL kernel is 6.18.35.2 (published 2026‑06‑19). The version string linux‑msft‑wsl‑6.18.35.2 encodes the upstream major version (6), the upstream minor release (18), the upstream stable sub‑version (35) and two rounds of Microsoft‑specific patches.

For reference the current mainline releases are:

Linux 7.1.3 – released 2026‑07‑04 (stable)

Linux 7.2‑rc3 – development release, July 2026

Why WSL does not use the newest kernel

Microsoft deliberately follows only Long‑Term Support (LTS) kernels. The WSL kernel history shows the LTS versions that have been adopted:

2020 (WSL2 launch) – 4.19 LTS

2021‑2022 – 5.10 LTS

2022‑2024 – 5.15 LTS

2024‑2026 – 6.6 LTS (configuration overhaul, loadable‑module support)

2026‑present – 6.18 LTS (supported until Dec 2027)

The 2019 Microsoft blog states that the WSL kernel is rebased only when a new LTS is designated, so non‑LTS releases such as 7.1 are intentionally skipped. Users must wait for the next LTS in the 7.x series before WSL can adopt it.

All distributions share the same kernel

Ubuntu, Debian and Arch running under WSL all use the single WSL kernel. Demonstrations:

Running apt install linux-image-7.1 has no effect because initramfs and GRUB are irrelevant in WSL.

Executing uname -r in any of the three distros returns the identical version string.

After wsl --shutdown, all distros boot the newly installed kernel (if an update occurred).

Kernel updates are performed with wsl --update or via Windows Update, not with apt upgrade.

How Microsoft brings a new kernel into WSL (six‑step process)

Step 1 – Selection: track the LTS designated by kernel.org

When the Linux community announces a new LTS, the WSL team marks it as the target. The first 6.18‑based build ( 6.18.20.1) was released within two weeks of the LTS designation.

Step 2 – Pull upstream and apply WSL‑specific out‑of‑tree patches

Microsoft maintains a set of out‑of‑tree patches. The most visible categories are:

dxgkrnl – GPU sharing, enables Linux programs in WSL to use the Windows host GPU (still out‑of‑tree).

virtio‑fs – Optimized file‑share protocol between WSL and Windows (partially upstreamed).

hv_sock – Hyper‑V socket IPC (Windows ↔ Linux); upstreamed since 6.18.35.1.

Hyper‑V clock/timer – ARM64 synthetic clock support (partially out‑of‑tree).

swiotlb pool – DMA pool for Hyper‑V PCI devices (out‑of‑tree).

The 6.18 update dramatically reduced the out‑of‑tree patch set because many patches (e.g., virtio‑PMEM, hv_utils clock sync, hv_sock error handling) were accepted upstream.

Step 3 – Compile with the trimmed config‑wsl configuration

The kernel is built using the Microsoft‑maintained Microsoft/config‑wsl file. This configuration disables hardware drivers and filesystems unnecessary for WSL, such as SATA/NVMe/USB storage drivers, non‑ext4 filesystems, and desktop peripherals (sound, Wi‑Fi, Bluetooth). The result is a minimal, fast‑booting, low‑memory kernel.

Step 4 – CI/CD build and automated testing

Microsoft compiles the kernel on an internal Azure Linux 3 toolchain (GCC) via CI/CD pipelines and runs automated test suites.

Step 5 – Distribution via Windows Update

WSL kernels are delivered through the standard Windows Update service (automatic) or manually via wsl --update, which uses the Microsoft Store update channel.

Step 6 – User activation

After an update the user must run wsl --shutdown to terminate all WSL sessions; the next launch loads the new kernel.

Replacing the kernel yourself

Users can compile a custom kernel and point WSL to it with a .wslconfig file placed in %USERPROFILE%\.wslconfig:

[wsl2]
kernel=C:\Users\YourUserName\bzImage

Typical build steps inside WSL:

# Clone Microsoft’s WSL kernel repository
git clone https://github.com/microsoft/WSL2-Linux-Kernel.git --depth=1 -b linux-msft-wsl-6.18.y
cd WSL2-Linux-Kernel
# Install build dependencies
sudo apt install build-essential flex bison libssl-dev libelf-dev bc python3 pahole cpio
# Build with Microsoft’s config
make -j$(nproc) KCONFIG_CONFIG=Microsoft/config-wsl
# Copy the image to the Windows side
cp arch/x86/boot/bzImage /mnt/c/Users/YourUserName/

After wsl --shutdown and restarting WSL, uname -r shows the custom version. A self‑built kernel loses Microsoft’s automatic updates and signature verification, so it is suitable only for users who need specific kernel features.

Quick reference

Current WSL kernel version: 6.18.35.2 (Linux 6.18 LTS + Microsoft patches).

Why not 7.1? Because 7.1 is not an LTS; Microsoft follows only LTS releases.

When will a 7.x kernel appear? After the next 7.x version is designated LTS and Microsoft completes the adaptation.

Do all distributions share the kernel? Yes – Ubuntu, Debian, Arch all run the same WSL kernel.

How to update the kernel? Run wsl --update or let Windows Update push it.

What are Microsoft’s “magic” patches? dxgkrnl (GPU), virtio‑fs, hv_sock, Hyper‑V clock/timer, swiotlb pool, plus a trimmed kernel configuration.

Can the kernel be replaced? Yes – compile your own and point to it via .wslconfig.