WSL2 Kernel 6.18.54.1 Adds DirectX Native Fence Sharing, Restores DRM and PPP

What the release lists​

The release notes name these changes:

• An update to stable kernel v6.18.54.
• A forward port of feature/arm64-hyperv-synthetic-clocks-timers/6.18.
• A forward port of feature/swiotlb-pool/6.18.
• PPP support re-enabled.
• DRM and VGEM re-enabled.
• ISO9660 built in rather than built as a module.
• BPF LSM enabled by default.
• DXGKRNL native fence sharing support, credited to Karthikeyan Singaram.

Phoronix describes the tag as Microsoft's WSL-tailored downstream copy of the Linux 6.18 LTS kernel. It says the update brings in the latest upstream bug and security fixes. The release notes themselves don't name any CVEs or specific fixes. Treat "security fixes" as the general nature of a stable-kernel bump, not a claim about a particular vulnerability.

The headline item: DXGKRNL native fence sharing​

DXGKRNL is Microsoft's out-of-tree Linux driver behind DirectX and GPU access in WSL2. Its original introduction described it as exposing a /dev/dxg device to Linux user mode. It talks over the VM bus to its counterpart on the Windows host, which communicates with the physical GPU.

The commit is titled "dxgkrnl: native fence sharing support." Per the commit text, it makes several changes:

• Native fence create and open operations now use the global VMBus channel, with the channel lock held.
• The host's global sync object comes back through an explicit output parameter. Before, it overloaded the device-handle field, so the guest device handle is now preserved for the later open call.
• Results are copied to user mode before the handle is published. A failed copy_to_user can therefore no longer leave a handle visible to user mode.
• An extra kref_get is dropped after handle assignment, to match the reference counting in dxgkio_create_sync_object.
• Native fences get the same teardown handling as monitored fences: device-list removal and I/O-space unmapping.
• The sync-file paths now guard against a null sync point.

The commit also splits the VMBus interface version. Version 40 stays as the feature baseline. A new "latest" constant of 46 serves as the advertised negotiation ceiling. The commit says this keeps the extended header working for hosts on versions 40 to 45, and lets native-fence creation work on a v45 host. It also checks the host NTSTATUS on the create path and cleans up logging. The commit touches eight files, with 1,079 additions and 22 deletions.

What this does and doesn't tell you​

The code describes native fences as a lightweight synchronization primitive that can be shared across processes. Such primitives are typically used for GPU-to-GPU and GPU-to-CPU synchronization. That is the code's description, not a benchmark. Nothing in the release notes or commit gives performance figures, names applications that benefit, or states a minimum Windows or GPU driver requirement. The VMBus version details suggest the host side matters, since creation and NT-handle opening are tied to specific interface versions. Microsoft hasn't documented which Windows builds provide them, so I won't guess.

The configuration changes​

The release notes give no rationale for any of these, so read them narrowly:

• DRM and VGEM re-enabled. This doesn't automatically mean all Linux graphics features now work in WSL2.
• PPP re-enabled. The notes name no specific networking scenario.
• ISO9660 built in. This changes how the support is packaged, from module to built-in. It doesn't by itself add new ISO-mounting capability.
• BPF LSM on by default. The kernel can now host BPF-based security modules. That doesn't mean any policy is enforced out of the box.

This also fits the recent trend. The earlier 6.18.40.1 release significantly trimmed the kernel configs. It removed support for hardware never exposed to WSL guests and disabled several debug options. The re-enabled items in this tag read like selective restorations after that trim, though Microsoft hasn't said so.

Getting it, and the custom-kernel route​

I couldn't verify how or when Microsoft will roll this tag to standard WSL installs, so don't assume wsl --update delivers it today. Microsoft's documentation says wsl --update updates WSL itself. Its wsl --status command reports general WSL configuration, including the kernel version. Microsoft's docs also list wsl --version for component versions.

A quick way to check what you're running is to open PowerShell and run wsl --version. Look at the kernel version line. A tag like 6.18.54.1 would show as a 6.18.54-based kernel.

If you build or supply your own kernel, Microsoft's .wslconfig documentation covers it:

1. Create .wslconfig in your %UserProfile% folder if it doesn't exist. It isn't created by default.
2. Under the [wsl2] section, set kernel= to an absolute Windows path, using escaped backslashes as in Microsoft's example.
3. Optionally set kernelModules= to a modules VHD path.
4. Run wsl --shutdown, wait for the VM to stop, then relaunch your distribution.

A malformed .wslconfig doesn't stop WSL from launching. It simply means the settings aren't applied. These steps apply only to custom kernels. Users on the default Microsoft-provided kernel don't need them.

The build story has had bumps before. One earlier issue report described a dxgkrnl build failure on a 6.18.20.1 kernel, caused by a __dma_fence_is_later signature mismatch. If you compile your own WSL kernel, build and test this tag before relying on it.

Context​

Phoronix notes this arrives after WSL 3.0.2, which added support for very large servers and experimental sparse VHD storage. That was a separate release. Those features are not part of this kernel tag's listed changes.

One analysis notes WSL stays on LTS kernels, so 6.18 remains the base even though newer non-LTS Linux versions exist. That is an outside commentary source, not Microsoft, but it matches the 6.18 lineage seen here.

Bottom line​

This is a routine but meaningful kernel refresh. The stable update is the safest takeaway. The native fence sharing patch is the notable engineering change, and the configuration restorations may matter to users with specific workloads. For most WSL users, there is no confirmed visible change. For anyone running GPU-heavy Linux workloads or custom kernels, it's worth watching how the tag reaches stable WSL builds, and how the native fence support gets used.