[ALERT] CVE-2026-31431 - Local Privilege Escalation Vulnerability

Announcements Stable Updates
,
1

Local Privilege Escalation Vulnerability

On 29 April 2026, a high local privilege escalation vulnerability in the Linux kernel, tracked as CVE-2026-31431 and named “Copy Fail”, was publicly disclosed. The vulnerability affects Manjaro Linux since 2017. A public proof-of-concept exploit has been released.

The release manager has patched most of the kernels and released them to the testing and unstable branches:

[Testing Update] 2026-05-01 - Kernels (CVE-2026-31431), NVIDIA, LibreOffice, Mesa, Deepin - #2 by discobot

Temporary Mitigation

Disable the algif_aead kernel module persistently on all affected systems until a patched kernel is available:

# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# rmmod algif_aead 2>/dev/null || true

This workaround does not affect dm-crypt /LUKS, kTLS , IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. It may affect applications explicitly configured to use the afalg engine or that bind aead/skcipher/hash sockets directly. Exposure can be assessed with lsof | grep AF_ALG .

– CERT-EU - High Vulnerability in the Linux Kernel (“Copy Fail”)

If you check your exposure - first sync lsof-package to your system pacman -Syu lsof.

What you can do

If you think you are a target for an exploit like this, consider switching to testing branch.

sudo pacman-mirrors -aS testing && sudo pacman -Syyu

If testing or unstable branch is not an option then consider building a temporary kernel for your system

[How To] Compile a custom Manjaro kernel

Alert your system administrator

If you are part of a multi-user system running on Manjaro stable branch and kernel 6.18.18 consider informing the administrator responsible for the server you are connecting to.

Community kernel

:warning: Use the kernel on your own responsibility.
:reminder_ribbon: No efforts has been made to ensure compatibility with any extra-modules
:reminder_ribbon: No efforts has been made to ensure compatibility with Nvidia GPU drivers
:reminder_ribbon: The kernel exist side-by-side with the official 6.18 kernel and must be maintained separately.
:reminder_ribbon: No updates to the patch will be provided and you must manually switch back when stable branch receives a patched kernel.

You can get the community kernel for stable branch from https://manjaro.dk/kernel/.

sudo pacman -U https://manjaro.dk/kernel/linux618-patch-6.18.26-1-x86_64.pkg.tar.zst

A header package is also available should you require it.

The packages are signed using a valid Manjaro Linux signing key. The key belongs to Frede Hundewadt AKA @linux-aarhus.

9 Likes
5

Thanks for giving prominence to this!

Two suggestions:

  • Because the 618 kernel that is currently available in testing (6.18.26) works perfectly on the rest of the stable distro, please make as soon as possible a stable update with that kernel. There is no need for a huge update to stable. Even updating just linux618 and linux612 alone (the two more recent LTS and recommented kernels) will do.

  • As an alternative approach to the issue, those wishing to remain on stable rather than disabling the algif_aead may consider manually downloading linux618-6.18.26-1-x86_64.pkg.tar.zst and linux618-headers-6.18.26-1-x86_64.pkg.tar.zst from some manjaro mirror and install them. This has the advantage that when stable updates the kernel, the system will at some point automatically align to the “stable” kernel. This avoids the risk of forgetting to remove the file disabling algif_aead once a new kernel makes that mitigation unnecessary.

1 Like
6

I thought of that - I wouldn’t do it - at least not with any important production systems.

I would switch branch instead

As linux618 depends on coreutils and coreutils depends on glibc and glibc is newer on testing and unstable it may introduce hard to figure out issues.

Dependency info 
 $ pamac info linux618
Name                  : linux618
Version               : 6.18.26-1
...
Depends On            : coreutils initramfs kmod
...

 $ pamac info coreutils
Name                  : coreutils
Version               : 9.11-1
...
Depends On            : acl attr glibc gmp libcap openssl
...

 $ mbn info coreutils -q
...
Branch         : unstable
Name           : coreutils
Version        : 9.11-1
Repository     : core
Build Date     : Mon 20 Apr 2026 16:58:00 
Packager       : Tobias Powalowski <tpowa@archlinux.org>
Branch         : testing
Name           : coreutils
Version        : 9.11-1
Repository     : core
Build Date     : Mon 20 Apr 2026 16:58:00 
Packager       : Tobias Powalowski <tpowa@archlinux.org>
Branch         : stable
Name           : coreutils
Version        : 9.10-1
Repository     : core
Build Date     : Wed 04 Feb 2026 17:59:19 
Packager       : Tobias Powalowski <tpowa@archlinux.org>

 $ mbn info glibc -q
...
Branch         : unstable
Name           : glibc
Version        : 2.43+r22+g8362e8ce10b2-1
Repository     : core
Build Date     : Tue 21 Apr 2026 12:13:48 
Packager       : Frederik Schwan <freswa@archlinux.org>
Branch         : testing
Name           : glibc
Version        : 2.43+r22+g8362e8ce10b2-1
Repository     : core
Build Date     : Tue 21 Apr 2026 12:13:48 
Packager       : Frederik Schwan <freswa@archlinux.org>
Branch         : stable
Name           : glibc
Version        : 2.43+r5+g856c426a7534-1
Repository     : core
Build Date     : Mon 09 Feb 2026 12:31:58 
Packager       : Frederik Schwan <freswa@archlinux.org>
2 Likes
7

Updating the kernel to a later patch level of the same kernel generation should not have any repercussions on account of glibc or coreutils.

It should be perfectly safe to push out a kernel-only update. We’ve done it before, and quite frankly, I don’t understand why we’re not doing it now, other than that one particular individual who shall not be named is being lazy.

4 Likes
10

Getting the patched kernel update to stable is probably the ideal solution. Since people will be able to see that there’s an update and protect themselves immediately. Especially since not everyone visits the forums regularly or follows the latest Linux news…

5 Likes
12

I second this (= the comment of @Randomname123) because that’s what I´d expect from an enterprise grade or an Arch-but-user-friendly distribution. The other solutions (switching to testing branch or downloading and installing a newer kernel or compiling and installing a newer kernel) are more like sysadmin tasks. I can do that and am willing to learn to do that but it conflicts with my interpretation of the Manjaro branding…

1 Like
13

Please see

1 Like