Linux Kernel ptrace issue

(This blogpost is not written in my usual style; it’s more of “get something out quick so I can send to my friends” thing)

TLDR:

attacks have been shown that (a) read ssh host keys and (b) read /etc/shadow
- https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn
requires local user who can run arbitrary code
- there is a very small chance that a browser based exploit can do this; at least I have not read anything to the contrary
scenarios:
- servers with untrusted users (e.g., university systems, enterprise systems!!) ARE at risk
- private server with trusted user and not running arbitrary software, and definitely no browsers, is not at risk (e.g., my personal VPS, heh!)
- desktop with no inbound ssh use, and with strong passwords on recent OS are also OK, as long as they are using yescrypt for the hashing
  - second field in /etc/shadow entry should start with $y$
  - if in doubt, change the password to any user that operates a browser or is prone to running arbitrary junk
  - you can change it to the same password; the objective is to update the hash algorithm in /etc/shadow
  - (or, manually check what users’ shadow entries don’t start with $y$ and change only those, then check to make sure)
immediate steps to mitigate, if you think you are at risk:

(NOTE: Chrome’s sandboxing may be affected by this; I lack the motivation to follow up, because I use Chrome only to access Microsoft Teams, and even that very rarely).
```
cat /proc/sys/kernel/yama/ptrace_scope
# will likely show "1"
sysctl kernel.yama.ptrace_scope=2
# immediate fix
cat /proc/sys/kernel/yama/ptrace_scope
# should show 2
echo kernel.yama.ptrace_scope=2 > /etc/sysctl.d/ptrace-vuln.conf
# longer term fix
```
Source: https://www.openwall.com/lists/oss-security/2026/05/15/8