dxgkrnl: FORTIFY "field-spanning write" WARNING from dxgvmb_send_wait_sync_object_gpu() on every boot

[Hekzory]

Windows Version

Microsoft Windows [Version 10.0.26220.7872]

WSL Version

2.7.5.0

Are you using WSL 1 or WSL 2?

WSL 2

Kernel Version

6.18.26.1-microsoft-standard-WSL2

Distro Version

Arch Linux (rolling)

Other Software

WSLg / Xwayland — the kernel trace shows Comm: Xwayland, so that's what triggers it.

Repro Steps

1. Boot a WSLg-enabled distro (Xwayland starts on its own; launching any GUI app also does it).
2. Check the kernel log: dmesg | grep -A20 field-spanning (or journalctl -k -b).

Happens on every boot here.

Expected Behavior

No kernel WARNING from dxgkrnl during normal GPU use.

Actual Behavior

dxgkrnl trips a CONFIG_FORTIFY_SOURCE check and logs a WARNING with a full stack trace, every boot, when Xwayland does a GPU-side sync-object wait. It points at dxgvmb_send_wait_sync_object_gpu() at dxgvmbus.c:3095.

Nothing actually breaks and the GPU works fine. It seems benign — a FORTIFY warning, not a panic — and I don't think it's a security issue, but flagging it since a WARNING splat on every boot is easy to mistake for something serious.

Diagnostic Logs

memcpy: detected field-spanning write (size 4) of single field "current_pos" at drivers/hv/dxgkrnl/dxgvmbus.c:3095 (size 0)
WARNING: CPU: 4 PID: 290 at drivers/hv/dxgkrnl/dxgvmbus.c:3095 dxgvmb_send_wait_sync_object_gpu+0x271/0x290
CPU: 4 UID: 1000 PID: 290 Comm: Xwayland Not tainted 6.18.26.1-microsoft-standard-WSL2 #1
Call Trace:
 <TASK>
 dxgkio_submit_wait_to_hwqueue+0x133/0x2e0
 dxgk_ioctl+0x66/0x110
 dxgk_unlocked_ioctl+0x12/0x20
 __x64_sys_ioctl+0xa1/0xf0
 do_syscall_64+0x72/0x990
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
 </TASK>

Happy to run collect-wsl-logs.ps1 if you want the full capture.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[Hekzory]

WslLogs-2026-05-19_00-35-04.tar.gz

[github-actions]

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Diagnostic information

.wslconfig found
Detected appx version: 2.7.5.0
Found no WSL traces in the logs

[Hekzory]

WslLogs-2026-05-19_01-12-27.tar.gz

[github-actions]

Diagnostic information

.wslconfig found
Detected appx version: 2.7.5.0

[chemwolf6922]

@chessturo . This seems to be a false positive by the FORTIFY detection. Could you please help take a look? Thanks.