Home > Control panel > Operations notices > Linux kernel vulnerability requiring VM restart (Copy Fail)

Related Links

Notice Links:

Notice

Linux kernel vulnerability requiring VM restart (Copy Fail)

PostedFri, 1 May 2026 04:10 AM UTC
Fri, 1 May 2026 00:10 AM EDT
Last UpdateSat, 2 May 2026 22:35 PM UTC (93 hours ago)
Sat, 2 May 2026 18:35 PM EDT
StatusClosed

Update at Sat, 2 May 2026 22:33 PM UTC: VMs are now running on new kernels.  We worked through a few restart issues with a few customers.  Now would be a good time to check your services are all running as expected.  Let us know if we can assist with anything!

A serious Linux kernel vulnerability has been publicly disclosed:

https://copy.fail/

This issue is tracked as CVE-2026-31431, also known as Copy Fail.

It affects many Linux kernels shipped from 2017 onwards. The issue allows a local unprivileged user or process to gain root privileges. In practical terms, if an attacker already has access to run code inside a VM, for example through a compromised website, shell account, or application, this bug may allow them to take full control of that VM.

We have pushed patched kernels to our VM hosts.

No action is required, but an urgent restart is strongly recommended

We will be restarting affected customer VMs with the patched kernel.  No action is required by you.  However, it is best if you can switch to the patched kernel as soon as possible rather than waiting for us.

Switching to the patched kernel

Your VM needs to be restarted to boot into the patched kernel.

You can restart it yourself now using one of these methods:

After the restart, your VM should be running the patched kernel.

You can check with:

uname -a

For example a fixed kernel looks like:

Linux example.com 6.6.0-really137-rh-20260430214815.xenU.x86_64 #1 SMP Thu Apr 30 22:06:25 UTC 2026 x86_64 GNU/Linux

The kernel version should show a build date of 20260430 or newer. Those digits are the date: 30 April 2026.

Your VM will be restarted

Because this is a serious privilege escalation issue and public exploit code is available, we will restart VMs that are still running an older kernel.

We will start those restarts from:

  • Friday 1 May, 22:00 UTC
  • Friday 1 May, 17:00 Dallas time
  • Saturday 2 May, 10:00 NZST

The restart should be a normal VM reboot. Your VM will be unavailable while it restarts.

We will not restart servers already on a patched kernel.

If you want to control the timing, please restart your VM before then.

If you do not want us to restart your VM, please open a support ticket and ask us to add this tag to your server notes:

#noautokernelfix

Please note that opting out means your VM may continue running a vulnerable kernel until you restart it yourself.

Notes

  • VPSs running our 4.14 and older kernels are not be vulnerable to this attack (pre 2017).
  • VPSs on our 4.19 or 5.4 kernels can typically be reliably switched on our kernel page to our 5.10 or newer kernels.
  • The kernel page will tell you which kernel will be used after the restart and which kernel it was booted on.  For example if it says "Booted on 5.10.0-really251-rh-20260304013052.xenU.x86_64" then that date string "20260304" means the kernel is from March and predates the fixed kernel (20260430 or newer).
  • VPSs using a custom kernel (ie via grub) should check with their kernel provider and update as soon as possible.
  • As usual please subscribe to this notice to receive updates on the situation.
#

Keep You Updated?

Log in to subscribe to changes to this notice.

Set your operation notice contact details for future notifications.