CVE-2026-31431 (Copy Fail - Linux kernel bug)

[tiago304]

Windows Version

Microsoft Windows [versão 10.0.26200.8246]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 24.04

Other Software

None needed.

Repro Steps

Fully updated WSL2 is affected by the Copy Fail (CVE-2026-31431) bug.

1 - Download the Copy Fail python script poc - https://copy.fail/
2 - Run the poc as a normal user
3 - Become root (Local Privilege Escalation)

$ whoami
tiago
$ uname -r
6.6.87.2-microsoft-standard-WSL2
$ ./copy_fail_exp.py
# whoami
root
#

Expected Behavior

After step 3, not become root.

Actual Behavior

Local Privilege Escalation

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

[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

Detected appx version: 2.6.3.0
Found no WSL traces in the logs

[tiago304]

I've reproduced the issue while the log collection was running and submitted the generated WslLogs-2026-04-30_01-01-04.tar.gz file.

This is a bug in the Linux kernel. Since Microsoft compiles its own version of the kernel, an action of Microsoft is required to fix the bug.
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

[tiago304]

/emailed-logs

[github-actions]

Diagnostic information

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

[chemwolf6922]

@chessturo , could you please help update / patch the kernel? Thanks.

[RageGen]

@chessturo, Please take a look, the kernel really requires an urgent patch, since it depends on the WSL platform itself and not on the distribution inside it, since updating both distributions will not affect the error and even disabling the algif_aead kernel module according to the manual from:
cve.org-CVE-2026-31431
Fix, on ask Ubuntu
It does not have an effect within the framework of WSL distributions, in general, the CVE is of a fairly high level based on the status assigned to it on cve.org what is the problem with patching the kernel explicitly? It is not entirely clear what exactly you want to see in the logs of the WSL itself, please specify which log is needed, the kernel? I'll provide it, but for now I'm attaching a screenshot of my reproduced case.

The exploit itself is literally now publicly available to everyone!
copy-fail-CVE-2026-31431

In my case:
WSL2
Ubuntu 24.04 and 26.04 fully affected.

Thank you! 😉

[ce7er2s]

@chemwolf6922 @tiago304 @RageGen
Since I don’t see any rush from Microsoft, probably this instruction can be helpful. It’s basically gonna compile a new kernel with the vulnerable module disabled.

Before compiling a kernel, make sure you have installed all dependencies. I built a kernel in Ubuntu WSL, and I’m not sure if it’s all you need in Arch WSL (though the kernel does work in both of my distros installed). Debian’s deps probably do not differ from Ubuntu’s.

Ubuntu:

sudo apt update
sudo apt install -y build-essential flex bison libssl-dev libelf-dev \
    bc dwarves cpio kmod rsync git

Arch:

sudo pacman -S --needed base-devel bc libelf pahole cpio perl tar xz git

Get sources from Microsoft’s official kernel repo. I picked the 6.6 kernel branch since it was my currently used one. Maybe there are other branches with a patch or faulty module disabled, but I don’t know for sure. As far as I know, 6.6 is an LTS release, but CVE is fixed only since 6.6.137.

git clone --depth=1 -b linux-msft-wsl-6.6.y \
    https://github.com/microsoft/WSL2-Linux-Kernel.git
cd WSL2-Linux-Kernel

This will copy the default config that is usually used with WSL and disable CRYPTO_USER_API_AEAD flag.

cp Microsoft/config-wsl .config
scripts/config --disable CRYPTO_USER_API_AEAD
make olddefconfig
make -j$(nproc)

Built kernel can be found at arch/x86/boot/bzImage.

UPD: Don't forget to install kernel modules, I completely forgot this part for some reason:

sudo make modules_install

Next thing you do: put it somewhere Windows can find it during a WSL startup. I put it at the default kernel location without changing the filename: C:\Program Files\WSL\tools\bzImage. Then specify this kernel in your HOME directory .wslconfig at C:\Users\<USER>\.wslconfig:

[wsl2]
kernel=C:\\Program Files\\WSL\\tools\\bzImage

Then you just shut down WSL2 and start it again:

wsl --shutdown
wsl

To verify that the correct kernel is used, just check what uname -r says. Expect a trailing + on the version string.

uname -r
# Should be something like this: 6.6.123.2-microsoft-standard-WSL2+

To check that vulnerability is mitigated, you can try to bind a socket with a faulty module:

python3 -c 'import socket; s=socket.socket(38,5); s.bind(("aead","gcm(aes)"))'

You probably will get something like that:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import socket; s=socket.socket(38,5); s.bind(("aead","gcm(aes)"))
                     ~~~~~~~~~~~~~^^^^^^
  File "/usr/lib/python3.14/socket.py", line 236, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 97] Address family not supported by protocol

Btw, it is also possible to apply a patch from Linus. Just do this instead of changing kernel config.

git remote add upstream https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch upstream a664bf3d603d --depth=1
git cherry-pick a664bf3d603d

There’s probably gonna be a merge conflict, but the patch is rather small, so backport can be done in no time ;)

UPD2: Just found out that default config (at Microsoft/config-wsl) already has CONFIG_CRYPTO_USER_API_AEAD=m, so it also can be mitigated with a widely proposed solution while being built cleanly (only if kernel modules are installed properly, otherwise there will be none available , which is also some form of mitigation probably).

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead

Though I believe that disabling it is still the best option.

[RageGen]

@ce7er2s Thank you, it works!