2.7.5

[benhillis]

What's Changed

• Update Microsoft.WSL.Kernel to 6.18.26.1 (Update Microsoft.WSL.Kernel to 6.18.26.1 #40161) by @chessturo
• Service: Best-effort grant of VMWP access to user-supplied VHDs (Service: Best-effort grant of VMWP access to user-supplied VHDs #40485) by @benhillis

Full Changelog: 2.7.3...2.7.5

---

This discussion was created from the release 2.7.5.

[benhillis]

This is our first release with a 6.18 kernel, please let us know if you are having any issues with the new major kernel version.

[valorisa]

Docker Desktop broken with 6.18 kernel — netlink ABI incompatibility

Hi @benhillis, thanks for flagging the opportunity to report 6.18-related issues here.

Summary

Docker Desktop (WSL2 backend) fails to start its docker-desktop distro when using a 6.18.x kernel. The LinuxKit initd binary crashes at boot with:

netlink: 'initd': attribute type 4 has an invalid length.

This affects both custom-built 6.18 kernels and (expected) the official 6.18.26.1 kernel shipped in WSL 2.7.5.

Root cause

Docker Desktop ships precompiled LinuxKit binaries (including initd) that were built against 6.6.x netlink headers. The netlink attribute validation was tightened in 6.18, causing these binaries to send malformed attributes from the 6.18 kernel's perspective.

This is a kernel ABI break at the netlink level — no kernel config or module-loading strategy can work around it. Docker needs to recompile their LinuxKit binaries for 6.18+ compatibility.

Reproduction steps

1. Use any WSL2 6.18.x kernel (custom or 2.7.5's official kernel)
2. Start Docker Desktop with WSL2 backend
3. Observe docker-desktop distro fails to boot
4. dmesg shows the netlink attribute error above

Impact

Anyone upgrading to WSL 2.7.5 (or using a custom 6.18 kernel) who relies on Docker Desktop will have Docker completely broken with no user-side workaround.

Possible mitigations

1. Short-term: Document the incompatibility in 2.7.5 release notes so users know to stay on 2.7.3 if they need Docker Desktop
2. Medium-term: Add a per-distro kernel= override in .wslconfig so docker-desktop distro can use the default 6.6 kernel while other distros use 6.18
3. Long-term: Coordinate with Docker to update their LinuxKit binaries for 6.18+ ABI

Related

• Feature request with full details: Custom kernel from linux-msft-wsl-6.18.y branch silently breaks Docker Desktop — no documentation or warning #40573
• My reproduction guide: https://github.com/valorisa/WSL2-Custom-Kernel-6.18-LTS-Guide

Happy to provide additional logs or test patches if needed.

[tinlittle]

I believe @benhillis meant to invite early adopters to report bug the usual way. IMO, it'd be better to file a normal issue and link it over here. Also, Docker should proactively address this and I am sure they are already testing it. MSFT will and shall not wait for OEM vendors like Docker to move forward with Linux kernel upgrades.

[valorisa]

These non-functional interactions between Docker and the WSL custom kernel have existed for years. I don’t know how all of this is handled internally. I simply reported the issue, which I’m not the only one experiencing. I created an issue on the WSL GitHub and the Docker/for-win GitHub. I’ve been testing custom WSL kernels for years and trying to resolve the issues they cause with Docker Desktop. No luck so far. If there’s a way to make it work, I’d be interested.

[benhillis]

Thanks for bringing this to my attention, I'll figure out a story here.

[benhillis]

And yes, let's move discussion of this to the GitHub issue you filed.

[valorisa]

OK

[valorisa]

Quick follow-up: the Docker Desktop versions I tested are 4.69, 4.71, 4.73.0, and 4.73.1 — all exhibit the same netlink ABI crash with the 6.18 kernel. So this isn't specific to one Docker release; it's any current version shipping LinuxKit binaries compiled against 6.6.x headers.

[sbradnick]

v2.7.5 doesn't work for me. I can't install a distro after updating from v2.7.3 to it and I can't run one that's fine with v2.7.3 - I just get:

This operation returned because the timeout period expired.
Error code: Wsl/Service/CreateInstance/CreateVm/0x800705b4

I've done a "Repair" from the v2.7.5 .msi and a reboot, same problem. Reinstalling v2.7.3 and all behaves.

EDIT: v2.7.5 doesn't work when Windows 11 is running virtually (in Linux, KVM) ; it's working as expected on a Lenovo laptop running Windows 11 directly. I've never seen this phenomenon in many years of using WSL.

[chemwolf6922]

Hi @sbradnick . Thanks for the info. Please consider open an issue and collect and share the log if you would like to repro this again. Thanks.

[attzonko]

@sbradnick Have you found a fix/workaround? I am on 2.7.8 and still seeing this issue when running WSL2 in a VM.

[sbradnick]

@sbradnick Have you found a fix/workaround? I am on 2.7.8 and still seeing this issue when running WSL2 in a VM.

No, I just use a prior version that doesn't suffer from the problem because I'm unaware of anything the last few versions provide being a necessary requirement for my testing. Since it works fine on a laptop running bare-metal windows, I haven't been overly interested in chasing down what may-or-may-not have changed in the interactions between KVM virtualized Win11 and WSL. Maybe I will if the next non-Pre Release version still does it, but I'm not overly interested in running the powershell scripts and the back-n-forth of uploading their results for these esoteric error messages (i.e. 0x800705b4).

[benhillis]

@sbradnick - can you please file an issue with a trace? I'm digging in but that would help.

[sbradnick]

@sbradnick - can you please file an issue with a trace? I'm digging in but that would help.

#40820