dirtyfrag security error in kernel (Like "Copy Fail")

[RageGen]

Windows Version

Microsoft Windows [Version 10.0.26200.8246]

WSL Version

WSL version: 2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Kernel version: 6.6.87.2-1

Distro Version

Ubuntu 24.04, 26.04

Other Software

No response

Repro Steps

Security error, same as CVE-2026-31431

Allows you to get root access on a local machine. The error comes from an unpatched Kernel module's - xfrm-ESP and RxRPC.

The code is publicly available in projects:

1. https://github.com/V4bel/dirtyfrag
2. https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo

Steps:

1. Run ./run.sh from second repo.

Expected Behavior

Error and no root access (with a rebuilt kernel without an error module, the exploit produces the expected result - on a standard WSL kernel, no).

Actual Behavior

I'm getting root access.

Diagnostic Logs

No response

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

[RageGen]

/emailed-logs

[github-actions]

Diagnostic information

Found '/emailed-logs', adding tag 'emailed-logs'

[RageGen]

@chemwolf6922 Thank you for tag, bro!

[thendricks0]

Adding this to the .wslconfig in Windows should help to mitigate the issues:

[wsl2]
kernelCommandLine=module_blacklist=esp4,esp6,rxrpc,algif_aead

Because blacklisting the modules via /etc/modprobe.d (as suggested for general Linux systems) did not mitigate the exploits for me inside WSL!
Also if you ran the dirtyfrag exploit on your systems, you must make sure to fix the su binary as it is replaced. Preferrably never run these exploits in your actual production WSL instance, always use a fresh instance to test them and remove them afterwards!
Under Ubuntu you can run sudo apt reinstall util-linux to reinstall the correct the su binary, for the people who ran this in their actual dev environments...

[RageGen]

@thendricks0 Yes, thank you for the alternative solution, but as I mentioned above, I took a more radical approach by recompiling the entire kernel without the vulnerable module. However, your solution is more elegant as it does not require a complete recompilation of the kernel.

[supervirus]

Also if you ran the dirtyfrag exploit on your systems, you must make sure to fix the su binary as it is replaced.

The exploit "only" overwrite parts in the kernel page cache, but the actual su binary is never changed on disc.

You can clear the page cache by running echo 3 > /proc/sys/vm/drop_caches and you will see that su is back to normal operation next time you run it.
So re-installing util-linux would be overkill...

But I agree, that running the exploit on a production machine is still a bad idea.

[NovaViper]

@RageGen Hey, what kernel version did you rebuild against?

[RageGen]

@NovaViper I recompiled the latest kernel available from Microsoft following the instructions from our neighboring discussion thread — #40365 (comment)

[RageGen]

Now i have:

ragegen@RageGen-PC:~$ uname -a
Linux RageGen-PC 6.6.123.2-microsoft-standard-WSL2+ #1 SMP PREEMPT_DYNAMIC Fri May  1 05:38:07 MSK 2026 x86_64 GNU/Linux