Linux Kernel ptrace Exit-race Vulnerability / ssh-keysign-pwn (CVE-2026-46333) — Mitigation and Kernel Update on CloudLinux

Right after the kernel privilege-escalation chain in the XFRM/ESP subsystem (Copy Fail, Dirty Frag, Fragnesia), Qualys disclosed a different Linux kernel issue. This time in the ptrace access-check path. CVE-2026-46333 is reserved for tracking this vulnerability. A public proof-of-concept exists. An unprivileged local user on an affected host can use it to read root-owned secrets (SSH host private keys and the shadow password database) without obtaining root privileges directly.

The flaw is a race in the kernel exit path (the do_exit code path). Between the moment a task's memory descriptor is detached and the moment its file descriptor table is closed, the kernel's ptrace access check skips its dumpable safeguard because the task's memory descriptor is already NULL. During that narrow window, an unprivileged process can call the file descriptor cloning interface introduced in Linux 5.6 (pidfd_getfd(2)) and copy open descriptors out of the exiting privileged process.

The targets are SUID binaries that legitimately open root-owned files during their normal exit path, primarily ssh-keysign (which reads the SSH host private keys) and chage (which reads the shadow password database). The race triggers on those binaries' normal exit, so no special configuration on the privileged side is required.

Details: public proof-of-concept · upstream fix — commit 31e62c2ebbfd · Qualys advisory (TBA) · NVD entry — CVE-2026-46333

Affected CloudLinux versions

CL7 is not affected. The kernel race was introduced upstream in v4.10-rc1 (2017, commit bfedb589); CL7's 3.10 kernel predates the regression entirely.

CL7h and CL8 are not exploitable by the current public proof-of-concept. The pidfd_getfd(2) interface required by the PoC is absent from their 4.18 kernel line (verified empirically: the syscall returns ENOSYS). However, the underlying kernel race is present in the 4.18 code line. An adapted PoC using direct ptrace_attach is in preparation by the security community; CL7h / CL8 will be patched on the same timeline as CL9 / CL10 regardless.

CloudLinux 8 LTS is a distinct case from CL8. While CL8 ships a 4.18 kernel without pidfd_getfd(2), CloudLinux 8 LTS ships a different kernel that does expose the syscall. The public proof-of-concept works directly against CL8 LTS hosts. Treat CL8 LTS as on the same risk level as CL9 / CL10. Apply mitigation 1 immediately if you are running CL8 LTS, and update to the patched LTS kernel as soon as it lands.

CL9 and CL10 are affected. See the available mitigations below for the details and side-effects of each mitigation listed in the table.

A KernelCare livepatch that automatically deploys the patched version without requiring a reboot will also be available as an alternative on all affected versions. See Stream 3 (KernelCare) below for current status.

Apply this mitigation now

There are three layers of mitigation, applicable independently or in combination. The recommended quick win is the CloudLinux-specific sysctl kernel.user_ptrace=0. It blocks the issue at the kernel level host-wide and is reversible with a single sysctl. Followed by CageFS (already protects caged tenants by default) and per-binary SUID-bit removal for the currently known targets.

1. Recommended: set kernel.user_ptrace=0 (CloudLinux-specific sysctl)

CloudLinux kernels expose a non-upstream sysctl kernel.user_ptrace that gates whether unprivileged users may invoke ptrace. Setting it to 0 blocks the issue at the kernel level for every account on the host, caged or not. Default is 1 (permissive). Verified empirically: the public proof-of-concept neutralizes on both CL9 and CL10 after this change.

Apply now (runtime, no reboot needed):

sudo sysctl -w kernel.user_ptrace=0

Persist across reboots:

echo 'kernel.user_ptrace = 0' | sudo tee /etc/sysctl.d/99-ptracenull.conf
sudo sysctl --system

To revert after a patched kernel is installed:

sudo rm /etc/sysctl.d/99-ptracenull.conf
sudo sysctl -w kernel.user_ptrace=1

Compatibility: with kernel.user_ptrace=0, unprivileged users can no longer attach gdb -p, strace -p, or perf trace --pid to their own processes. Monitoring agents that ptrace-attach without CAP_SYS_PTRACE will also break. On typical shared-hosting workloads this is acceptable; on developer or CI hosts, expect attach-debug to break for non-root users.

2. Already in place: CageFS protects caged tenants

3. Per-binary SUID-bit removal (covers currently known targets only)

If mitigation 1 cannot be used (because end users on the host legitimately rely on unprivileged ptrace) and CageFS is not enabled, remove the SUID bit from the two currently known proof-of-concept targets. Note: any SUID-root binary that opens privileged secrets during exit is a potential target — see the caveat below.

sudo chmod u-s /usr/libexec/openssh/ssh-keysign 2>/dev/null
sudo chmod u-s /usr/bin/chage

Verify the SUID bit is gone (the listing should start with -rwxr-xr-x, not -rwsr-xr-x):

ls -l /usr/libexec/openssh/ssh-keysign /usr/bin/chage

To revert after a patched kernel is installed:

sudo chmod u+s /usr/libexec/openssh/ssh-keysign 2>/dev/null
sudo chmod u+s /usr/bin/chage

Compatibility:

• ssh-keysign is only invoked by ssh(1) when the client is configured with HostbasedAuthentication yes. This authentication mode is rarely used in shared-hosting environments. If you do rely on host-based SSH authentication, do not remove the SUID bit from ssh-keysign. Use mitigation 1 instead.
• The chage SUID bit lets a non-root user query and change their own password aging information. Removing the SUID bit means only root can run it. Administrative use is unaffected.
• Any SUID-root binary that opens privileged secrets during exit is a potential target. Stripping the SUID bit from chage and ssh-keysign covers the binaries used by the published proof-of-concept but does not exhaustively cover the bug class. If you cannot apply mitigation 1, audit local SUID-root binaries for any that open root-owned files at exit time. Mitigation 1 closes the kernel path host-wide and is the recommended mitigation to the bug class.

Update instructions

There are three release streams. Use the one that applies to your CloudLinux version. As patches land, this article will be updated in place. Check the timestamps on the callouts in each stream below.

Stream 1 — CloudLinux kernel update (CL7h, CL8, CL8 LTS)

CL7h and mainstream CL8 share the AlmaLinux 8-derived kernel base (4.18.0-553.*.lve.el{7h,8}). The kernel-level fix is the same upstream commit 31e62c2ebbfd; CloudLinux ships it as a rebuild on top of the AlmaLinux 8 patched kernel.

CloudLinux 8 LTS ships a different kernel line that exposes pidfd_getfd(2). The patched LTS kernel lands via the CL8 LTS update channel.

Stream 2 — AlmaLinux kernel (CL9, CL10)

CloudLinux 9 and CloudLinux 10 use the AlmaLinux kernel directly. The patched kernel is expected to appear first in the AlmaLinux testing repository, with promotion to production repositories shortly after.

Installing from the AlmaLinux testing repository

The almalinux-release-testing package is not in CloudLinux repositories. Install it from a direct URL, update the kernel, then disable the testing repo.

For CL10:

# 1. Enable the AlmaLinux 10 testing repo
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm

# 2. Update the kernel
dnf update 'kernel*'

# 3. Reboot
reboot

# 4. Verify
uname -r

# 5. Disable the testing repo
dnf config-manager --disable almalinux-testing

For CL9 — same flow, replace the URL in step 1:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm

Once the kernel reaches AlmaLinux production repositories

A plain update pulls the patched version, no testing-repo step needed:

dnf update 'kernel*'
reboot
uname -r

Stream 3 — KernelCare livepatch

The KernelCare livepatch for this issue is being prepared. KernelCare ships it to the testing feed first and promotes to the main feed after validation. To deploy from the testing feed once available:

kcarectl --update --prefix test

Once promoted to the main feed, KernelCare-subscribed systems receive the fix automatically through the standard livepatch flow:

kcarectl --update

Not using KernelCare yet? You can roll out the patches for your entire fleet automatically, and without needing reboots. Get started in just a few minutes. Find more information here.

How to verify you are patched

After update + reboot:

uname -r

Compare to the target version for your CloudLinux stream above (target versions will be filled in once releases land).

For KernelCare, once a CVE is assigned, verify with kcarectl --patch-info:

kcarectl --patch-info | grep CVE-XXXX-XXXXX   # replace with the CVE

A non-empty line in the output means the CVE is patched on this system, for example:

[CVE-XXXX-XXXXX] Linux kernel ptrace exit-race information disclosure

If the output is empty, the patch is not applied yet — run kcarectl --update and re-check.

References

• Public proof-of-concept (ssh-keysign-pwn)
• Upstream fix — commit 31e62c2ebbfd in Linus tree
• Qualys advisory (TBA)
• NVD entry — CVE-2026-46333
• AlmaLinux advisory — CVE-2026-46333
• CloudLinux KB article
• CloudLinux status page