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.

[valorisa]

@sbradnick Thanks for reporting this — it's useful context. Your timeout error (CreateVm/0x800705b4) is different from the netlink ABI issue I reported (which only affects Docker Desktop's LinuxKit binaries), but both point to the same conclusion: 2.7.5 with its 6.18 kernel introduces regressions at multiple levels.

In your case, it seems the VM itself fails to start, which is more fundamental than my issue (where the VM boots but Docker's initd crashes inside it).

For now, staying on 2.7.3 is the safe path. @benhillis is aware of the Docker/netlink problem and said he'd "figure out a story here" — hopefully the broader 2.7.5 stability issues like yours get addressed in the same cycle.

Have you filed a separate issue for the timeout? If not, it might be worth it — your symptoms are distinct enough to warrant their own tracking.

[sbradnick]

Mine is just a general v2.7.5 comment, not related to what you've added under this 40548 discussion - which is why I didn't reply to anything you've posted here, to keep it separate.

I may open an issue for it, but I'm unsure where these pre-release items fit in 'grand scheme' wise and that effects my appetite to go down the logging rabbit-hole along w/ the fact that my Win11 install showing this issue is a Linux KVM [vm] even though this has been working for many years - v2.7.5 is the 1st instance of this type of failure and the same one works w/o issue/reboot going back to v2.7.3 ...

[valorisa]

Understood, and no worries — I realize now my reply may have conflated the two topics. Your timeout issue is clearly separate from the netlink/Docker problem I reported.

Regarding whether to file an issue: I get the hesitation. Pre-release tracking can feel like a grey area. That said, since your regression is reproducible (works on 2.7.3, fails on 2.7.5) and specific to a KVM-hosted Win11 — that's exactly the kind of signal the WSL team needs, especially given 2.7.5 ships the first 6.18 kernel. Even a short issue with "2.7.5 breaks WSL under Linux KVM, 2.7.3 works, timeout 0x800705b4" would be enough to get it on their radar without you having to dive deep into logs.

But totally your call — if you'd rather wait and see if a subsequent pre-release fixes it, that's reasonable too.

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