Mitigating CVE-2026-46333 (ptrace Dumpability Exploit) on Rocky Linux 8, 9, 10, and LTS Variants
Introduction
CVE-2026-46333 is a local privilege escalation vulnerability in the Linux kernel's ptrace subsystem, reported by the Qualys Security Advisory team. The flaw allows a local unprivileged user to bypass a dumpability check during process teardown and gain root access. A public proof-of-concept exploit is available.
This article covers Rocky Linux 8, 9, and 10 systems, including CIQ LTS, FIPS, and RLC Pro variants. It describes what is affected, how to apply the YAMA ptrace_scope mitigation, and how to confirm the mitigation is in effect. No patched kernels are available as of 2026-05-15.
Problem
The vulnerability is in __ptrace_may_access() in kernel/ptrace.c. During process exit, the kernel calls exit_mm() to clear task->mm before the process is fully gone. If another process calls pidfd_getfd() to steal file descriptors from the exiting process during this window, __ptrace_may_access() skips its dumpability check because task->mm is NULL. An unprivileged attacker can exploit this to steal writable file descriptors from privileged processes, including open handles to /etc/passwd and /etc/shadow, and write arbitrary content to those files to create a backdoor root user.
A second exploit path targets setuid binaries that open privileged files before dropping elevated privileges. A public proof-of-concept exploits ssh-keysign, which reads SSH host private keys while still running as root. A similar technique applies to the chage binary, which reads /etc/shadow before its privilege drop. Using ptrace to attach during this window, an attacker can read the contents of those files as an unprivileged user.
Both paths are blocked by the YAMA ptrace_scope mitigation described below.
The upstream fix is commit 31e62c2ebbfd, which adds a user_dumpable bit to task_struct to cache dumpability state before exit_mm() clears task->mm. This ensures the dumpability check is not skipped during the race window.
Treat the following systems as affected unless they have the mitigation in place or are running a patched kernel:
- Rocky Linux 9 and 10 community releases
- Rocky Linux 9 LTS variants (9.2, 9.4, 9.6)
- RLC Pro FIPS 9.x variants
- RLC Pro 9 and 10 variants, including RLC Pro Hardened
- CIQ Linux Kernel variants (CLK 6.12, CLK 6.18)
Rocky Linux 8 systems (kernel 4.18.x) contain the same bug in the ptrace code. However, the pidfd_getfd() system call was introduced in kernel 5.6, so the path used in the above exploit is not reachable on el8. The setuid binary race path via ssh-keysign or similar binaries may still expose /etc/shadow contents on el8 systems where YAMA is not enforced. Apply the mitigation on el8 as well to address that exposure.
Status
- No patched kernels are available as of 2026-05-15. The upstream fix (commit
31e62c2ebbfd) has not yet landed in any CIQ or RESF kernel build. CIQ will update this article with a Patched Kernels table once testing is complete. - Recommended action: apply the YAMA
ptrace_scopemitigation described below. - SELinux does not protect unmitigated systems. The default targeted SELinux policy places regular users in the
unconfined_tdomain, which is not constrained from using ptrace orpidfd_getfd. A standard Rocky Linux installation with SELinux enforcing remains exploitable until the mitigation is applied. - Open a support case if you need help assessing exposure on your fleet or tracking patched kernel availability for a specific CIQ variant.
Patched Kernels
No patched kernels are available as of 2026-05-15. CIQ will update this table as tested kernels become available for each variant.
Mitigation
Setting kernel.yama.ptrace_scope to 2 blocks both exploit paths. At scope 2, any ptrace() operation requires CAP_SYS_PTRACE, which an unprivileged user does not have. CIQ lab testing confirmed that ptrace_scope=2 blocks both the pidfd_getfd-based LPE and the ssh-keysign setuid race on Rocky Linux 9.6 LTS and Rocky Linux 10.1.
Checking for prior exploitation
If the exploit has already run on the system, check /etc/passwd for unauthorized UID 0 entries:
awk -F: '$3 == 0 {print}' /etc/passwd
The only expected output is the root entry. Any additional UID 0 entry indicates a successful privilege escalation. If found, treat the system as compromised and follow your incident response process.
Review the authentication log for unexpected privilege escalation or su activity that could indicate post-exploitation use of stolen credentials:
grep -E '(su|passwd|sudo)' /var/log/secure | tail -50
Applying the mitigation
Confirm YAMA is available on the running kernel before proceeding:
cat /proc/sys/kernel/yama/ptrace_scope
If the file exists and returns a value, YAMA is compiled in. YAMA is enabled by default on Rocky Linux 8, 9, and 10 kernels and all CIQ LTS, FIPS, and RLC Pro variants. If the file is absent, the kernel was built without CONFIG_SECURITY_YAMA and the sysctl approach will not work. This is uncommon on supported CIQ variants but may occur on custom or third-party kernels.
Warning:
kernel.yama.ptrace_scopeis a one-way ratchet in the running kernel. You can increase the value via sysctl without a reboot, but you cannot decrease it. Restoring a lower value requires a reboot. Test in a non-production environment before applying fleet-wide.
Warning: ptrace_scope=2 blocks all ptrace operations for unprivileged users. This affects strace, gdb, and other debugging tools when run without root, and any application that relies on ptrace-based process introspection. Validate against your workload before rolling out fleet-wide.
To apply the mitigation persistently:
echo "kernel.yama.ptrace_scope=2" | sudo tee /etc/sysctl.d/ptrace-scope.conf
sudo sysctl --system
The setting takes effect immediately. The file in /etc/sysctl.d/ ensures it persists across reboots.
Verification
Confirm the setting is active on the running kernel:
cat /proc/sys/kernel/yama/ptrace_scope
The output should be 2.
Confirm the persistent configuration file is in place:
cat /etc/sysctl.d/ptrace-scope.conf
You should see kernel.yama.ptrace_scope=2.
Reverting the Mitigation
Once a patched kernel is installed, the mitigation can be reverted. Because ptrace_scope cannot be lowered on a running kernel, reverting requires removing the config file and rebooting.
sudo rm /etc/sysctl.d/ptrace-scope.conf
sudo reboot
After the reboot, confirm the value has returned to the system default:
cat /proc/sys/kernel/yama/ptrace_scope
The output should be 0 on a standard Rocky Linux system with no other ptrace_scope configuration in place.
Removing SUID bits from known-affected binaries (supplementary)
As a supplementary measure, you can remove the SUID bit from the binaries the public exploit targets. This does not fix the underlying kernel bug and does not protect against other SUID binaries that may be reachable, but it blocks the known public proof-of-concept if you cannot apply the ptrace_scope mitigation immediately.
sudo chmod u-s /usr/libexec/openssh/ssh-keysign
sudo chmod u-s /usr/bin/chage
Note that removing the SUID bit from ssh-keysign breaks host-based SSH authentication for users who rely on it. Removing it from chage prevents unprivileged users from running chage to manage their own password expiry. Evaluate the impact on your environment before applying this to production systems. This is a targeted workaround, not a complete mitigation. Apply ptrace_scope=2 from the section above in addition to or instead of this step.
Notes
- ptrace_scope=3 also blocks the exploit. Scope 3 restricts ptrace to direct parent processes only, regardless of capability, making it more restrictive than scope 2 with a correspondingly larger impact on tooling. Scope 2 is sufficient to block both known exploit paths.
- One-way ratchet behavior. If you increase
ptrace_scopevia sysctl on a running system, the only way to lower it again is to reboot. Plan accordingly before applying the mitigation to systems where debugging tools need to remain available. - Public exploit availability. A working proof-of-concept is publicly available. Treat affected systems with local users, CI runners, or untrusted workloads as actively exploitable until the mitigation is applied or a patched kernel is installed.
- el8 exposure. Rocky Linux 8 systems cannot be exploited via the
pidfd_getfdpath, but applyingptrace_scope=2on el8 is still recommended to address the setuid binary race path and as a defense-in-depth measure.
References & related articles
- CVE-2026-46333 stable kernel releases (LWN)
- Public proof-of-concept: github.com/0xdeadbeefnetwork/ssh-keysign-pwn
- Upstream fix commit: 31e62c2ebbfd
- CVE-2026-46333 (NVD)
- CVE-2026-46333 (MITRE)
- kernel.yama.ptrace_scope documentation