Dealing with CVE-2024-1086

Back in January 2024 CVE-2024-1086 was published. Most distros picked up patches for this pretty quickly but unfortunately RHEL and subsequently AlmaLinux (along with other downstreams), lagged behind. Keeping in mind that AlmaLinux no longer strictly follows RHEL 1:1, it begs the question of why this wasn’t patched sooner. The simple answer is that with regard to doing our own patching outside of what Red Hat does we are still figuring out what that looks like. To date we mostly patch things that catch our eye as important for our users, or that users specifically ask us to patch. Unfortunately this CVE missed the former mark, but the latter worked and the severity of this was brought to our attention on March 29.

Red Hat has classified the severity of the issue as “Moderate”. While I am neither a security researcher nor a kernel developer, I believe the simplicity of the publicly available proof of concepts since the initial classification by Red Hat could warrant a re-evaluation. As of now, RHEL7 and CentOS 7 have received patched kernels. While RHEL8 and RHEL9 are pending updates, CentOS Stream 8 and 9, as well as RHEL 8 and 9 EUS branches (8.6, 8.8, 9.2), have been patched according to Red Hat. I anticipate this fix dropping for RHEL 8/9 in 8.10 and 9.4 as patches are currently in the BETA releases of those versions.

Now, going back to the fact that I’m not a kernel developer or a security researcher, at first the impact of CVE-2024-1086 seems pretty targeted and perhaps minimal. Looking a bit deeper into it and getting to what it really means is that any system with netfilter loaded and user namespaces enabled is vulnerable to rather trivial unprivileged user escalation. What systems have netfilter loaded and user namespaces enabled? ALL EL8 and EL9 variants do by default.

Using some proof-of-concept code, which is freely available on GitHub, I did my own quick testing against AlmaLinux 8 and AlmaLinux 9 and immediately realized the importance and severity of this for anyone with multi-user systems, especially if those users are potentially untrusted.

[testuser@exploit-test ~]$ id
uid=1000(testuser) gid=1000(testuser) groups=1000(testuser)
[testuser@exploit-test ~]$ ./exploit
[*] creating user namespace (CLONE_NEWUSER)...
[*] creating network namespace (CLONE_NEWNET)...
[*] setting up UID namespace...
[*] configuring localhost in namespace...
[*] setting up nftables...
[+] running normal privesc
[*] waiting for the calm before the storm...
[*] sending double free buffer packet...
[*] spraying 16000 pte's...
[*] checking 16000 sprayed pte's for overlap...
[+] confirmed double alloc PMD/PTE
[+] found possible physical kernel base: 0000000070000000
[+] verified modprobe_path/usermodehelper_path: 0000000071a61f80 ('/sanitycheck')...
[*] overwriting path with PIDs in range 0->4194304...
sh: cannot set terminal process group (-1): Inappropriate ioctl for device
sh: no job control in this shell
sh-5.1# id
uid=0(root) gid=0(root) groups=0(root)

As you can see, running this one simple exploit immediately gave me a root shell from an otherwise-unprivileged user.

In my testing, the exploit would generally crash the system shortly after execution, sometimes after a few seconds and sometimes after a couple of minutes - I didn’t look too much into how or why it crashed it because at that point it wasn’t very relevant to me - a root escalation was achieved and it had to be fixed, period.

At this point all efforts moved to patching. Luckily the upstream patch was easily backported to our kernels and on March 30 we created AlmaLinux 8 builds and AlmaLinux 9 builds. These kernels will be available in AlmaLinux production repositories by Monday, April 1.

To install these kernels in the meantime you can do so as follows:

dnf upgrade --repofrompath cve-2024-1086,https://build.almalinux.org/pulp/content/builds/AlmaLinux-8-$(arch)-8987-br

dnf upgrade --repofrompath cve-2024-1086,https://build.almalinux.org/pulp/content/builds/AlmaLinux-9-$(arch)-8923-br/

Both of these are signed with AlmaLinux package signing, and secure boot keys and ready for production.

I also managed to build kpatch patches for AlmaLinux 8.9 (4.18.0-513*), 9.2 (5.14.0-284*), and 9.3 (5.14.0-362*) kernels. These patches can be applied to a live running kernel without a reboot to patch the vulnerability. I can build patches for pre-8.9 and pre-9.2 kernels if there is demand.

These patches come with all the usual warnings: I am not a kernel developer. There is no warranty. Use at your own risk. I am not responsible if these patches crash or otherwise harm your system(s).

How to install, apply, and verify application:

YELLOW='\033[0;33m'
NC='\033[0m' # No Color
dnf -y install kpatch
curl --silent -f -O https://jonathanspw.com/files/AlmaLinux-$(rpm --eval '%rhel')--$(uname -r|cut -d. -f1-3|sed 's/\./-/g')--CVE-2024-1086-Patch.ko || printf "${YELLOW}Unsupported kernel.  Please request it via comments and provide the following information: $(grep -E '^NAME=' /etc/os-release): $(uname -r)${NC}"
kpatch load AlmaLinux-$(rpm --eval '%rhel')--$(uname -r|cut -d. -f1-3|sed 's/\./-/g')--CVE-2024-1086-Patch.ko

These patches have received at least minimal testing and basic functionality checks (no immediate crashes) on the following AlmaLinux x86_64 kernels:

I will update this post as these patches receive more testing on other kernel versions. They will probably work against other EL distros such as Rocky Linux or EuroLinux, but I have not tested this.

To verify it is loaded:

$ kpatch list
Loaded patch modules:
AlmaLinux_8_CVE_2024_1086_Patch [enabled]

Installed patch modules:

This will only load the patch into the currently running kernel. I’d suggest only loading it live, not “installing” it which will auto load it after reboot. In addition to loading it into the running kernel, install the updated kernel for AlmaLinux 8 or 9, version kernel-4.18.0-513.18.2 or kernel-5.14.0-362.24.2 respectively using the above test repos, or dnf upgrade kernel once the updated builds hit production repos.

The kpatch files above are signed with my GPG key.

File: https://jonathanspw.com/files/AlmaLinux-8--4-18-0-513--CVE-2024-1086-Patch.ko
Signature: https://jonathanspw.com/files/AlmaLinux-8--4-18-0-513--CVE-2024-1086-Patch.ko.sig
MD5 Checksum: 2a831eb09aa0d021b4ed5a2a4bdb8f46
SHA256 Checksum: 855e9c1c51a18936625c120d9c856d1bdcf154adca1489092cf299375d808473

File: https://jonathanspw.com/files/AlmaLinux-8--4-18-0-477--CVE-2024-1086-Patch.ko
Signature: https://jonathanspw.com/files/AlmaLinux-8--4-18-0-477--CVE-2024-1086-Patch.ko.sig
MD5 Checksum: 9f14f5dedff6b56b23909809a6775096
SHA256 Checksum: ae6e6b4d112a625cd559944edc1f6742b65d2bf2fa59b29434558de9adc0f30a

File: https://jonathanspw.com/files/AlmaLinux-9--5-14-0-362--CVE-2024-1086-Patch.ko
Signature: https://jonathanspw.com/files/AlmaLinux-9--5-14-0-362--CVE-2024-1086-Patch.ko.sig
MD5 Checksum: 3a1d75575c3872a66071d375c11d7535
SHA256 Checksum: 446a2f0a78f92a5530c45d443680171536888c4e6f6a3edaff95a412ca1aafbe

File: https://jonathanspw.com/files/AlmaLinux-9--5-14-0-284--CVE-2024-1086-Patch.ko
Signature: https://jonathanspw.com/files/AlmaLinux-9--5-14-0-284--CVE-2024-1086-Patch.ko.sig
MD5 Checksum: 7677bf81ce552c575bfd06cc8cedee0d
SHA256 Checksum: 7c802fcda5008c508ad0f1af451e92b3337346b57fb74ae293a201accc392d0e

• Updated April 1, 2024 to add EL8.8 kernel patches.