WSL Kernel 6.18.35.2 Fixes x86 Timekeeping Regression From Wrong MSR

Microsoft shipped WSL2 Linux kernel 6.18.35.2 on June 19, 2026, a targeted patch that corrects an x86 timekeeping regression quietly introduced in last week's 6.18.35.1 drop. The single fix resolves an architecture mismatch where an ARM64-specific timer register constant was incorrectly applied to x86 guests, producing garbage time values on systems that fall back to the Hyper-V reference counter instead of a CPU-native TSC.

A Regression Born in the ARM64 Port​

When Microsoft's kernel team forward-ported commit 668afdaec0e1 — "arm64: hyperv: Fix build breakage for non-ARM64 architectures" — to the 6.18 branch, a name-collision introduced a silent but serious error. The ARM64 register constant HV_REGISTER_TIME_REF_COUNT and the x86 MSR constant HV_MSR_TIME_REF_COUNT share nearly identical names but refer to entirely different hardware interfaces. On ARM64 hardware, both names resolve correctly. On x86, using HV_REGISTER_TIME_REF_COUNT reads a register that simply does not exist in the same way, returning noise.
Kernel contributor Mitchell Levy identified the mistake and submitted the correction: swap in HV_MSR_TIME_REF_COUNT, which the architecture-dispatch layer resolves to the correct MSR for the running CPU. The fix was merged into the 6.18.35 rolling-LTS branch on June 17 and tagged for release two days later.
The underlying issue sits in the Hyper-V synthetic clock and timer subsystem, a component that WSL2 inherits wholesale because it runs as a Hyper-V lightweight utility VM. Every time the Linux kernel inside WSL2 needs to read wall time and cannot use the CPU's hardware TSC, it falls back to querying Hyper-V's reference time counter through this MSR path. With the wrong constant in place, the fallback returned corrupted values.

Who Actually Feels This​

The regression only surfaces on x86 WSL2 guests where the kernel's preferred clocksource — the TSC — is unavailable or untrusted. Modern consumer CPUs ship with an invariant TSC that Hyper-V marks as reliable, so most everyday Windows 11 laptops and desktops are not affected. The Hyper-V reference counter fallback kicks in on older x86 hardware without a TSC invariant flag, or on certain nested-virtualization setups where the inner guest's TSC is masked.
For anyone who does hit this path, the consequences go beyond a subtly wrong clock widget. Time-sensitive developer tools — build systems that check file modification timestamps, test harnesses that enforce timeouts, logging pipelines that rely on monotonic time, cryptographic code that checks certificate validity windows — all misbehave when the system clock returns garbage. Users in affected configurations on 6.18.35.1 would have seen tools like make skipping rebuilds incorrectly, Node.js timestamp arithmetic producing wild values, and container runtimes logging events with impossible timestamps.
If you updated WSL last week and noticed any of those symptoms, 6.18.35.2 is the fix.

What 6.18.35.1 Already Fixed (Carried Forward)​

The 6.18.35.2 build carries everything shipped in last week's 6.18.35.1 release, so users who skipped that update get both drops at once.
The headline fix in 6.18.35.1 was a virtio-fs DMA size mismatch correction contributed by Microsoft engineer Ben Hillis: fuse: virtio_fs: clamp max_pages_limit by the transport DMA mapping size. The root cause: the Linux swiotlb layer caps a single DMA mapping at 256 KiB, but the FUSE driver's default of 256 pages yields a max_write of 1 MiB — four times the transport ceiling. On any write that exceeded the boundary, the kernel attempted a DMA mapping that the host transport rejected, returning -EIO mid-write. The fix clamps virtio-fs request sizing via virtio_max_dma_size(), the same pattern already used by virtio-blk. Users saw this as mysterious I/O errors during large file copies or heavy database writes against WSL virtio-fs mounts.
Also bundled: a DAX inode release hang fix (fuse: mark DAX inode releases as blocking), which prevented certain WSL virtio-fs unmounts from completing; and the hv_sock cleanup (hv_sock: Return -EIO for malformed/short packets, hv_sock: Report EOF instead of -EIO for FIN), which aligned WSL's Hyper-V socket error reporting with correct POSIX semantics so applications reading from closed vsock connections receive a clean EOF rather than an unexpected I/O error. The hv_sock patches were previously carried as private WSL-only patches; 6.18.35.1 retired them in favor of the upstream equivalents, reducing Microsoft's out-of-tree maintenance burden.

The 6.18 Kernel Line: A Brief Upgrade Timeline​

For readers tracking WSL's overall progression: WSL app release 2.7.5 on May 15, 2026 was the first version to ship a 6.18-based kernel (6.18.26.1), replacing the previous 6.6.x line. A follow-up app release, WSL 2.7.8 on June 6, fixed a separate issue where CreateInstance would fail on Windows machines whose hosts file exceeded roughly 1 MB — a condition triggered by some ad-blocker configurations. That fix raised the internal config message size cap from 4 MB to 16 MB and skips embedding oversized hosts content. Neither of those app-layer changes is part of this kernel-only release, but they provide the surrounding context for where WSL stands heading into today's 6.18.35.2 drop.

Key Takeaways​

• WSL kernel 6.18.35.2 ships one fix: the wrong Hyper-V timer MSR constant on x86 — HV_REGISTER_TIME_REF_COUNT (ARM64-only) swapped for HV_MSR_TIME_REF_COUNT (x86-correct) — that broke timekeeping on guests without an invariant TSC
• Affected users: x86 WSL2 on older hardware or nested-virtualization setups where the TSC invariant is not available; modern consumer PCs with invariant TSC are not affected
• Symptoms to look for: incorrect build timestamps, make skipping rebuilds, container log clock drift, certificate validation failures, test timeouts behaving wrongly
• All upstream Linux 6.18.35 changes came in 6.18.35.1 (June 12) — not in this release
• Carried forward from 6.18.35.1: virtio-fs DMA size mismatch fix, DAX unmount hang fix, hv_sock EOF/EIO cleanup, dedicated swiotlb pool for Hyper-V VPCI devices

To pick up the update, run wsl --update from a Windows terminal or let Windows Update deliver it automatically. Verify the active kernel version with uname -r inside any WSL2 distro — the output should read 6.18.35.2-microsoft-standard-WSL2 or similar.

---

References​

1. Official release — linux-msft-wsl-6.18.35.2: Microsoft / WSL2-Linux-Kernel
   Published: June 19, 2026
   
   

   Release linux-msft-wsl-6.18.35.2 · microsoft/WSL2-Linux-Kernel · GitHub

   The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2) - Release linux-msft-wsl-6.18.35.2 · microsoft/WSL2-Linux-Kernel

   github.com
2. Official release — linux-msft-wsl-6.18.35.1: Microsoft / WSL2-Linux-Kernel
   Published: June 12, 2026
   
   

   Release linux-msft-wsl-6.18.35.1 · microsoft/WSL2-Linux-Kernel · GitHub

   The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2) - Release linux-msft-wsl-6.18.35.1 · microsoft/WSL2-Linux-Kernel

   github.com
3. WSL 2.7.8 release notes: Microsoft / WSL
   Published: June 6, 2026
   
   

   Release 2.7.8 · microsoft/WSL · GitHub

   Windows Subsystem for Linux. Contribute to microsoft/WSL development by creating an account on GitHub.

   github.com
4. Microsoft upgrades WSL2 kernel to Linux 6.18 LTS: Phoronix
   
   

   Microsoft Upgrades Its WSL2 Kernel Against Linux 6.18 LTS - Phoronix

   Microsoft on Friday released linux-msft-wsl-6.18.20.1 as the Windows Subsystem for Linux 2 (WSL2) kernel updated against the Linux 6.18 LTS series.

   www.phoronix.com