ssh-keysign-pwn (CVE-2026-46333): Patched kernels available in testing

If you’re keeping a tally at , this is the fourth local-root Linux kernel disclosure we have written in roughly two weeks. At this rate the AlmaLinux build servers and core team are going to start getting hazard pay.

The new flaw is tracked as CVE-2026-46333 , and is being called ssh-keysign-pwn after one of the two public exploits. Qualys reported the underlying bug to [email protected] and Linus pushed the fix on 2026-05-14 in commit 31e62c2ebbfd . Hours later, “_SiCk” published two working exploits : one that reads /etc/ssh/ssh_host_*_key (via ssh-keysign ), and one that reads /etc/shadow (via chage -l ).

__ptrace_may_access() skips its dumpable check when the target task’s mm is NULL . During do_exit() , the kernel runs exit_mm() before exit_files() , so there is a window where a privileged process has dropped its mm but still has its file descriptors open. An unprivileged process running under the same uid can call pidfd_getfd(2) during that window and lift open file descriptors out of the dying process. If those descriptors point at root-owned files that the privileged binary opened before dropping privileges (e.g. SSH host keys opened by ssh-keysign before permanently_set_uid() , or /etc/shadow opened by chage before setreuid() ), the attacker now has a handle on them.

Jann Horn flagged the same shape back in October 2020 . Six years later, here we are.

AlmaLinux 9 and 10 are both vulnerable. The public exploits work reliably on both.

AlmaLinux 8 is not exploitable with the current public PoCs , but the underlying logic bug is present in the 4.18 kernel and we are not interested in waiting for someone to write a working exploit before we ship a fix. AlmaLinux 8 is getting the patch as well.

These kernels are available in the testing repository today. Once the community has helped verify them, they will be released to the production repositories. This post will be updated when that happens.

These builds also carry the Fragnesia patches, which are themselves still in the testing repository and have not yet rolled to production. Installing these kernels gets you the fix for both ssh-keysign-pwn and Fragnesia in one reboot.

Confirm with uname -r or rpm -q kernel against the versions above.

If you do not want the testing repo enabled afterwards (and on a production box you almost certainly do not), disable it once you have rebooted:

If you run into anything, please let us know in AlmaLinux chat or on bugs.almalinux.org .

Kitten 10 is a development release and does not have a separate testing repository. The dedicated patched build for Kitten ( kernel-6.12.0-227.el10 ) is still in the build queue at the time of writing and has not yet been published to Kitten’s regular repository. We will update this post and push the package out as soon as the build completes. When it does, the upgrade is just:

Qualys has confirmed a simple mitigation: tightening Yama’s ptrace_scope . Setting it to 2 (admin-only attach) or 3 (no attach) blocks every public exploit we are aware of:

ptrace_scope=3 disables ptrace attach entirely, which can break debuggers ( gdb attaching to a running process, strace -p , etc.). If you need ptrace for local debugging on the affected box, use 2 instead, which restricts attach to admins. Either value blocks the known PoCs because they rely on pidfd_getfd(2) ’s access check, which routes through __ptrace_may_access() .

This is a workaround, not a fix. Other paths to the same bug may exist. Install the patched kernel and reboot when you can.

Thanks to Qualys for reporting the bug and to Linus Torvalds for landing the fix the same day. Thanks to _SiCk for the proofs of concept that made the impact unambiguous, even if their release schedule did not give distributions a lot of room to breathe. And thanks again to the AlmaLinux core team, who at this point are starting to know the backport workflow for these kernels by muscle memory.

To the community: thank you for testing. Four kernel rebuilds in two weeks is a lot to ask, and the speed at which you have been verifying and reporting back is what keeps these patches moving from testing to production safely. We will keep building them as long as upstream keeps finding them. If the cadence ever slows down we promise to write a much more boring blog post.