Microsoft released WSL Kernel 6.18.35.1 on June 12, 2026, through the WSL2 Linux kernel project, updating Windows Subsystem for Linux 2 to upstream Linux 6.18.35 and adding a virtio-fs fix for oversized DMA mappings that could fail with
WSL Kernel 6.18.35.1 looks, at first glance, like the kind of update only a kernel maintainer could love. Microsoft’s release notes list a 6.18.35 stable-kernel rebase, a virtio-fs DMA-mapping fix from Ben Hillis, and the removal of another Microsoft-carried Hyper-V socket patch because the relevant fix is now upstream. There is no new shell experience, no visible WSLg trick, no developer keynote moment.
That is the point. WSL’s most important work in 2026 is not proving that Linux can run on Windows. That argument is over for the people who actually use it. The real test is whether the pieces beneath daily work — file access, virtualized devices, host-guest communication, kernel servicing, and integration patches — can keep improving without forcing users to care.
Version 6.18.35.1 is therefore best read as a maintenance release with one very practical center of gravity. The virtio-fs fix is not a decorative patch. It addresses a situation where WSL’s Linux guest could build requests larger than the transport layer could safely map for DMA, producing
That is not an abstract kernel-theory problem. A file-system transport that fails in the wrong way can poison trust faster than almost anything else in a development environment. Developers will forgive a missing GUI nicety. They will not forgive a platform that makes file operations feel arbitrary.
The patch description is unusually useful because it explains the failure path. virtio-fs negotiates
The numbers make the problem concrete. The effective per-mapping cap in the described path is 256 KiB, while the FUSE default of 256 pages produces a 1 MiB
That word, wedge, is the one administrators should remember. A clean error is annoying. A wedged queue is the sort of failure that sends developers into rituals: restarting WSL, shutting down distros, rebooting Windows, blaming Docker Desktop, blaming antivirus, blaming a corporate endpoint agent, and finally deciding that WSL is “flaky” without knowing why.
The fix follows the same pattern virtio-blk already uses: ask the transport for its maximum DMA size and cap the virtio-fs connection’s
This is good platform engineering because it reduces the number of impossible states. Rather than waiting for a too-large request to fail at the DMA layer, Microsoft’s kernel now shapes the negotiated file-system behavior around the transport’s real constraints. That is the difference between a subsystem that merely works in the happy path and a subsystem that knows where the guardrails are.
But convenience creates pressure. The more developers treat WSL as a normal Linux environment, the more they expect file operations to behave like normal Linux file operations. They want source trees to build quickly, package managers to behave predictably, containers to see consistent state, and tools to stop caring whether a path originated on the Windows side or the Linux side.
That expectation is where WSL’s file story gets hard. Windows and Linux do not share the same assumptions about metadata, locking, case sensitivity, permissions, path semantics, notification models, and caching. Add virtualization, shared folders, FUSE, virtio transports, and security controls, and a simple file read becomes a negotiation among several layers that were never designed as one system.
The virtio-fs fix in 6.18.35.1 is not a sweeping answer to all of that. It is narrower and more valuable than that: it removes a class of oversized request that could fail below the level most users can diagnose. It is the kind of patch that does not make a benchmark chart sing but can make a workstation feel less haunted.
That matters because WSL is used increasingly as a development substrate rather than a novelty shell. A local Linux environment on Windows may be hosting a language runtime, a package cache, a source repository, a container workflow, a database, and a test harness. When the file transport misbehaves, the symptom may surface far away from the cause.
A developer may see a failed install, a hung directory listing, a container build that stalls, or a tool reporting input/output errors. The underlying issue may be neither the package manager nor the application. It may be a transport-level mismatch in how much data the guest tried to map at once.
Stable-kernel updates are where many of the repairs users never notice are accumulated. The 6.18.35 changelog includes fixes across virtualization, networking, USB, graphics, memory management, filesystems, tracing, platform drivers, and device-specific code. Some are irrelevant to a typical WSL session. Some may never be reachable from Microsoft’s stock WSL configuration. The important point is not universal applicability; it is that WSL continues to track a maintained kernel branch instead of drifting into a private time capsule.
The upstream changelog contains exactly the sort of fixes that make systems people uncomfortable in a familiar way. There are use-after-free and double-free fixes, out-of-bounds checks, memory-corruption fixes for malicious or malformed USB endpoints, a CHAP base64 decode validation fix in the iSCSI target path, a memfd sealing correction around writable mappings, and crash fixes in tracing and networking-related code.
That does not turn WSL 6.18.35.1 into a panic-button security release. Microsoft did not describe it that way, and WSL’s exposed surface is not identical to a bare-metal Linux host. But it does reinforce a basic security truth: kernel stability and kernel security overlap more often than release-note labels admit.
For Windows users, this is one of the strange adjustments WSL requires. You may be running Windows 11, updating Windows through Windows Update, using a Microsoft Store-distributed WSL package, and launching Ubuntu or Debian from Terminal. Underneath that everyday workflow is a Linux kernel with its own upstream maintenance stream and its own reason to stay current.
That hybrid model is powerful, but it asks users and administrators to stop thinking in single-version terms. The Windows build matters. The WSL application version matters. The distro userland matters. The WSL kernel matters. A failure in one layer can masquerade as a problem in another.
Out-of-tree patches are a kind of institutional debt. Sometimes they are necessary, especially for WSL, which sits at a peculiar intersection of Linux, Windows, Hyper-V, device emulation, and developer expectations. But every private patch Microsoft carries has to be rebased, retested, reconciled with upstream changes, and explained when behavior differs from mainstream Linux.
When a patch becomes unnecessary because the fix is upstream, WSL becomes less special in the best possible way. The kernel is easier to update. The behavior is easier to reason about. Bugs are easier to report. Developers have fewer reasons to wonder whether they are hitting Linux, WSL, Hyper-V, or some Microsoft-only branch of reality.
This is particularly important for host-guest communication paths such as Hyper-V sockets. Most users do not know or care which transport or channel is carrying a given integration feature. They care that Linux on Windows feels coherent. The less Microsoft has to maintain separately, the more WSL can behave like a participant in the Linux ecosystem rather than an elaborate downstream exception.
The virtio-fs patch, interestingly, moves in the opposite direction for now: it is a Microsoft-carried fix in the WSL tree. That is not hypocrisy. It is how platform work evolves. Some patches are born downstream because a particular environment exposes a real problem first. The healthiest long-term outcome is that those fixes either remain narrowly WSL-specific for a good reason or eventually flow upstream when they apply more broadly.
The pattern to watch is not whether Microsoft has zero private patches. That is unrealistic. The pattern to watch is whether the private patch set keeps shrinking where upstream has absorbed the work and remains targeted where WSL genuinely needs integration glue. On that measure, 6.18.35.1 is a constructive release.
That is how infrastructure earns its place. The highest compliment a kernel file-transport fix can receive is that nobody files the same mysterious bug again. In the best case, this release removes one more reason for developers to treat WSL as something that works until it suddenly doesn’t.
The strongest candidates to benefit are users whose workflows touch virtio-fs paths heavily. That may include workloads with large directory traversals, repeated writes, build systems that churn through many files, language package managers, container-adjacent development, and scenarios where WSL’s file-sharing machinery is under enough pressure for request sizing to matter.
It is worth being careful here. Microsoft’s release note does not say every WSL user was affected, and the patch does not imply that all file I/O problems in WSL were caused by this bug. WSL still has multiple file-access paths, and performance or correctness issues can arise from repository location, antivirus scanning, Windows-mounted paths, distro storage, corporate endpoint tools, and application behavior.
But the specific failure class is real enough to merit a kernel release note. When the guest negotiates a request size the transport cannot DMA-map, the problem is not user confusion. It is a platform mismatch. Fixing that mismatch is exactly what a serviced kernel is supposed to do.
Developers should verify the running kernel rather than assume they have it. Inside a WSL distro,
That is not a reason to ban WSL. It is a reason to manage it honestly. WSL is not just a terminal window. It is a Linux runtime with a serviced kernel, virtualized devices, host integration, distribution images, user-controlled configuration, and in some cases custom kernels. That is enough moving machinery to deserve inventory.
The 6.18.35.1 release gives IT teams a useful example. If developers report intermittent
The same applies to security review. Upstream Linux 6.18.35 includes many stable fixes, some of which belong to the familiar family of memory-safety, bounds-checking, and crash-prevention work. Not all of them are reachable in WSL. Not all of them are relevant to a given company. But no serious security team should be comfortable with an unmanaged Linux kernel running at scale just because the window title says Windows Terminal.
A mature WSL policy does not have to be heavy. It should answer simple questions. Which WSL package channel is approved? Are preview builds allowed? How are kernel updates received? Which distributions are supported? Can developers use custom kernels? Are Windows-mounted repositories allowed for performance-sensitive builds, or should teams standardize on the Linux filesystem? Who owns escalation when a WSL kernel update changes behavior?
Those are not theoretical governance questions. They are the practical difference between WSL as a productive developer platform and WSL as a fleet of snowflakes.
That distinction matters for 6.18.35.1. A developer who has configured a custom kernel will not automatically receive Microsoft’s virtio-fs DMA clamp in the runtime that actually executes. The WSL package may be fresh. The release notes may be known. The running kernel may still be an older local build without the patch.
This is not a flaw in custom-kernel support. It is the trade-off. Custom kernels replace Microsoft’s stock servicing path with the user’s own maintenance responsibility. That can be exactly right in a lab and exactly wrong when it becomes an undocumented workaround on a production developer laptop.
The danger is invisibility. A developer may have set up a custom kernel months ago to test a feature, forgotten about it, and continued working as though WSL updates still define the kernel. When a fix like 6.18.35.1 ships, that developer does not get the behavioral change unless the custom kernel is rebuilt or the configuration is removed.
Administrators should treat custom WSL kernels the way they treat local certificate stores, special drivers, or unsupported endpoint exceptions. They may be necessary, but they need an owner. If nobody can say why a machine is using a custom kernel, the safest assumption is that the exception has outlived its justification.
-EIO during file operations. The change is narrow, but it lands in exactly the place where WSL’s promise is most vulnerable: the boundary between Windows-hosted virtualization and Linux file semantics. This is not a feature release pretending to be infrastructure. It is infrastructure revealing what still has to be made boring.
Microsoft’s New WSL Kernel Is a File-System Story Wearing a Version Number
WSL Kernel 6.18.35.1 looks, at first glance, like the kind of update only a kernel maintainer could love. Microsoft’s release notes list a 6.18.35 stable-kernel rebase, a virtio-fs DMA-mapping fix from Ben Hillis, and the removal of another Microsoft-carried Hyper-V socket patch because the relevant fix is now upstream. There is no new shell experience, no visible WSLg trick, no developer keynote moment.That is the point. WSL’s most important work in 2026 is not proving that Linux can run on Windows. That argument is over for the people who actually use it. The real test is whether the pieces beneath daily work — file access, virtualized devices, host-guest communication, kernel servicing, and integration patches — can keep improving without forcing users to care.
Version 6.18.35.1 is therefore best read as a maintenance release with one very practical center of gravity. The virtio-fs fix is not a decorative patch. It addresses a situation where WSL’s Linux guest could build requests larger than the transport layer could safely map for DMA, producing
-EIO failures and wedging the request virtqueue.That is not an abstract kernel-theory problem. A file-system transport that fails in the wrong way can poison trust faster than almost anything else in a development environment. Developers will forgive a missing GUI nicety. They will not forgive a platform that makes file operations feel arbitrary.
The virtio-fs Fix Says the Quiet Part Out Loud
The WSL-specific patch in this release clamps virtio-fs request sizing to the maximum single DMA mapping the transport can actually support. In plainer terms, the guest should not negotiate a file-operation request size that the underlying virtualization path cannot map. The old behavior could let virtio-fs advertise a larger effectivemax_write than the transport could handle.The patch description is unusually useful because it explains the failure path. virtio-fs negotiates
max_pages, which feeds into max_write. But when the device is behind a bouncing DMA layer, such as swiotlb=force, the actual per-mapping limit can be much smaller than the default request size. The patch says WSL enables that mode whenever a virtio-fs device is present.The numbers make the problem concrete. The effective per-mapping cap in the described path is 256 KiB, while the FUSE default of 256 pages produces a 1 MiB
max_write. That mismatch can produce read, readdir, or write requests whose buffers cannot be DMA-mapped. The failure is not merely a rejected operation; the patch says the request virtqueue can wedge.That word, wedge, is the one administrators should remember. A clean error is annoying. A wedged queue is the sort of failure that sends developers into rituals: restarting WSL, shutting down distros, rebooting Windows, blaming Docker Desktop, blaming antivirus, blaming a corporate endpoint agent, and finally deciding that WSL is “flaky” without knowing why.
The fix follows the same pattern virtio-blk already uses: ask the transport for its maximum DMA size and cap the virtio-fs connection’s
max_pages_limit accordingly. When there is no meaningful DMA limit, the helper returns a value large enough that the clamp is a no-op. When there is a limit, the guest stops building requests the transport cannot honor.This is good platform engineering because it reduces the number of impossible states. Rather than waiting for a too-large request to fail at the DMA layer, Microsoft’s kernel now shapes the negotiated file-system behavior around the transport’s real constraints. That is the difference between a subsystem that merely works in the happy path and a subsystem that knows where the guardrails are.
WSL’s File Boundary Is Becoming the Platform’s Load-Bearing Wall
File access has always been the emotional core of WSL. The first thrill of the subsystem was not just runningbash on Windows; it was moving between Windows files and Linux tools without changing machines. That convenience is still what makes WSL sticky for developers who live in both worlds.But convenience creates pressure. The more developers treat WSL as a normal Linux environment, the more they expect file operations to behave like normal Linux file operations. They want source trees to build quickly, package managers to behave predictably, containers to see consistent state, and tools to stop caring whether a path originated on the Windows side or the Linux side.
That expectation is where WSL’s file story gets hard. Windows and Linux do not share the same assumptions about metadata, locking, case sensitivity, permissions, path semantics, notification models, and caching. Add virtualization, shared folders, FUSE, virtio transports, and security controls, and a simple file read becomes a negotiation among several layers that were never designed as one system.
The virtio-fs fix in 6.18.35.1 is not a sweeping answer to all of that. It is narrower and more valuable than that: it removes a class of oversized request that could fail below the level most users can diagnose. It is the kind of patch that does not make a benchmark chart sing but can make a workstation feel less haunted.
That matters because WSL is used increasingly as a development substrate rather than a novelty shell. A local Linux environment on Windows may be hosting a language runtime, a package cache, a source repository, a container workflow, a database, and a test harness. When the file transport misbehaves, the symptom may surface far away from the cause.
A developer may see a failed install, a hung directory listing, a container build that stalls, or a tool reporting input/output errors. The underlying issue may be neither the package manager nor the application. It may be a transport-level mismatch in how much data the guest tried to map at once.
Linux 6.18.35 Brings the Usual Stable-Kernel Unease
The upstream Linux 6.18.35 rebase is the broader half of the release. Linux 6.18 is now a long-term kernel line, and 6.18.35 is a stable maintenance update in the traditional sense: a large batch of fixes backported from upstream development into a maintained branch. That makes it easy to dismiss, and that would be a mistake.Stable-kernel updates are where many of the repairs users never notice are accumulated. The 6.18.35 changelog includes fixes across virtualization, networking, USB, graphics, memory management, filesystems, tracing, platform drivers, and device-specific code. Some are irrelevant to a typical WSL session. Some may never be reachable from Microsoft’s stock WSL configuration. The important point is not universal applicability; it is that WSL continues to track a maintained kernel branch instead of drifting into a private time capsule.
The upstream changelog contains exactly the sort of fixes that make systems people uncomfortable in a familiar way. There are use-after-free and double-free fixes, out-of-bounds checks, memory-corruption fixes for malicious or malformed USB endpoints, a CHAP base64 decode validation fix in the iSCSI target path, a memfd sealing correction around writable mappings, and crash fixes in tracing and networking-related code.
That does not turn WSL 6.18.35.1 into a panic-button security release. Microsoft did not describe it that way, and WSL’s exposed surface is not identical to a bare-metal Linux host. But it does reinforce a basic security truth: kernel stability and kernel security overlap more often than release-note labels admit.
For Windows users, this is one of the strange adjustments WSL requires. You may be running Windows 11, updating Windows through Windows Update, using a Microsoft Store-distributed WSL package, and launching Ubuntu or Debian from Terminal. Underneath that everyday workflow is a Linux kernel with its own upstream maintenance stream and its own reason to stay current.
That hybrid model is powerful, but it asks users and administrators to stop thinking in single-version terms. The Windows build matters. The WSL application version matters. The distro userland matters. The WSL kernel matters. A failure in one layer can masquerade as a problem in another.
Fewer Microsoft-Only Patches Is a Quiet Win for Everyone
The other notable line in Microsoft’s release notes is almost bureaucratic: fewer out-of-tree patches, because the Hyper-V socket fixes previously carried in Microsoft’s WSL patch set are now included upstream. That line is easy to overlook because it sounds like housekeeping. It is more important than that.Out-of-tree patches are a kind of institutional debt. Sometimes they are necessary, especially for WSL, which sits at a peculiar intersection of Linux, Windows, Hyper-V, device emulation, and developer expectations. But every private patch Microsoft carries has to be rebased, retested, reconciled with upstream changes, and explained when behavior differs from mainstream Linux.
When a patch becomes unnecessary because the fix is upstream, WSL becomes less special in the best possible way. The kernel is easier to update. The behavior is easier to reason about. Bugs are easier to report. Developers have fewer reasons to wonder whether they are hitting Linux, WSL, Hyper-V, or some Microsoft-only branch of reality.
This is particularly important for host-guest communication paths such as Hyper-V sockets. Most users do not know or care which transport or channel is carrying a given integration feature. They care that Linux on Windows feels coherent. The less Microsoft has to maintain separately, the more WSL can behave like a participant in the Linux ecosystem rather than an elaborate downstream exception.
The virtio-fs patch, interestingly, moves in the opposite direction for now: it is a Microsoft-carried fix in the WSL tree. That is not hypocrisy. It is how platform work evolves. Some patches are born downstream because a particular environment exposes a real problem first. The healthiest long-term outcome is that those fixes either remain narrowly WSL-specific for a good reason or eventually flow upstream when they apply more broadly.
The pattern to watch is not whether Microsoft has zero private patches. That is unrealistic. The pattern to watch is whether the private patch set keeps shrinking where upstream has absorbed the work and remains targeted where WSL genuinely needs integration glue. On that measure, 6.18.35.1 is a constructive release.
Developers Will Notice the Fix Only When Their Workflow Stops Lying to Them
The most likely user-visible effect of WSL Kernel 6.18.35.1 is the absence of a failure. That is unsatisfying for release marketing but ideal for anyone who works at a terminal all day. If a virtio-fs request no longer wedges because it was too large for the DMA path, the developer does not see a success banner. The directory listing simply returns. The write simply completes. The build simply moves on.That is how infrastructure earns its place. The highest compliment a kernel file-transport fix can receive is that nobody files the same mysterious bug again. In the best case, this release removes one more reason for developers to treat WSL as something that works until it suddenly doesn’t.
The strongest candidates to benefit are users whose workflows touch virtio-fs paths heavily. That may include workloads with large directory traversals, repeated writes, build systems that churn through many files, language package managers, container-adjacent development, and scenarios where WSL’s file-sharing machinery is under enough pressure for request sizing to matter.
It is worth being careful here. Microsoft’s release note does not say every WSL user was affected, and the patch does not imply that all file I/O problems in WSL were caused by this bug. WSL still has multiple file-access paths, and performance or correctness issues can arise from repository location, antivirus scanning, Windows-mounted paths, distro storage, corporate endpoint tools, and application behavior.
But the specific failure class is real enough to merit a kernel release note. When the guest negotiates a request size the transport cannot DMA-map, the problem is not user confusion. It is a platform mismatch. Fixing that mismatch is exactly what a serviced kernel is supposed to do.
Developers should verify the running kernel rather than assume they have it. Inside a WSL distro,
uname -r tells the truth about the Linux kernel currently running. From Windows, wsl --version tells a related but different story about the WSL package and components. Those two commands should be in every WSL troubleshooting script and every help-desk macro for developer workstations.Enterprise IT Should Treat WSL Like a Runtime, Not a Convenience App
WSL’s adoption curve inside organizations has created a management problem that looks small until it becomes expensive. Developers install it because they need Linux tooling. Teams build workflows around it because it is faster than provisioning separate Linux machines. Administrators tolerate it because it remains inside the Windows estate. Then one day, a kernel update becomes relevant to builds, containers, file access, and security posture.That is not a reason to ban WSL. It is a reason to manage it honestly. WSL is not just a terminal window. It is a Linux runtime with a serviced kernel, virtualized devices, host integration, distribution images, user-controlled configuration, and in some cases custom kernels. That is enough moving machinery to deserve inventory.
The 6.18.35.1 release gives IT teams a useful example. If developers report intermittent
-EIO behavior, stalled file operations, or strange failures around shared file-system workloads, the WSL kernel version is now a first-order diagnostic fact. So is whether the machine is using Microsoft’s stock kernel or a custom kernel specified in .wslconfig.The same applies to security review. Upstream Linux 6.18.35 includes many stable fixes, some of which belong to the familiar family of memory-safety, bounds-checking, and crash-prevention work. Not all of them are reachable in WSL. Not all of them are relevant to a given company. But no serious security team should be comfortable with an unmanaged Linux kernel running at scale just because the window title says Windows Terminal.
A mature WSL policy does not have to be heavy. It should answer simple questions. Which WSL package channel is approved? Are preview builds allowed? How are kernel updates received? Which distributions are supported? Can developers use custom kernels? Are Windows-mounted repositories allowed for performance-sensitive builds, or should teams standardize on the Linux filesystem? Who owns escalation when a WSL kernel update changes behavior?
Those are not theoretical governance questions. They are the practical difference between WSL as a productive developer platform and WSL as a fleet of snowflakes.
Custom Kernels Can Hide the Fix From the People Who Need It
WSL’s custom-kernel support remains one of its most important power-user features. It allows kernel developers, researchers, and advanced teams to test patches, enable unusual options, or run specialized builds. It also means a machine can appear current while booting something else entirely.That distinction matters for 6.18.35.1. A developer who has configured a custom kernel will not automatically receive Microsoft’s virtio-fs DMA clamp in the runtime that actually executes. The WSL package may be fresh. The release notes may be known. The running kernel may still be an older local build without the patch.
This is not a flaw in custom-kernel support. It is the trade-off. Custom kernels replace Microsoft’s stock servicing path with the user’s own maintenance responsibility. That can be exactly right in a lab and exactly wrong when it becomes an undocumented workaround on a production developer laptop.
The danger is invisibility. A developer may have set up a custom kernel months ago to test a feature, forgotten about it, and continued working as though WSL updates still define the kernel. When a fix like 6.18.35.1 ships, that developer does not get the behavioral change unless the custom kernel is rebuilt or the configuration is removed.
Administrators should treat custom WSL kernels the way they treat local certificate stores, special drivers, or unsupported endpoint exceptions. They may be necessary, but they need an owner. If nobody can say why a machine is using a custom kernel, the safest assumption is that the exception has outlived its justification.
The DMA Clamp Is the Part of 6.18.35.1 Worth Remembering
WSL Kernel 6.18.35.1 is not a dramatic release, but it is a concrete one. Its practical value is that Microsoft has patched a specific file-system transport mismatch while continuing to rebase WSL on a maintained Linux long-term kernel. For WindowsForum readers, the update is less about chasing a version number than understanding which layer changed and why it matters.- WSL Kernel 6.18.35.1 updates Microsoft’s WSL2 Linux kernel to upstream stable Linux 6.18.35.
- The release includes a WSL-specific virtio-fs fix that clamps request sizing to the transport’s maximum single DMA mapping size.
- The bug could allow read, readdir, or write requests to exceed what the DMA path could map, leading to
-EIOfailures and a wedged request virtqueue. - Microsoft’s release notes say Hyper-V socket fixes previously carried as WSL out-of-tree patches are now included upstream.
- Developers should verify the running kernel with
uname -rinside WSL rather than assuming the WSL package version tells the whole story. - Organizations using custom WSL kernels must rebuild or retire those kernels if they want Microsoft’s 6.18.35.1 behavior.
