Re: Logic bug in the Linux kernel's __ptrace_may_access() function

[Salvatore Bonaccorso <carnil () debian org>]

Hi

On Fri, May 15, 2026 at 03:29:56AM +0100, Sam James wrote:
> Qualys Security Advisory <qsa () qualys com> writes:
>
> > Hi all,
> >
> > Today a vulnerability that we reported to security@kernel was fixed:
> >
> >   https://github.com/torvalds/linux/commit/31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a
> >
> > [...]
> >
> > Today we also contacted the linux-distros@openwall, but since exploits
> > are already public we were told to send this to oss-security@openwall
> > instead, hence this post. We are not publishing our advisory yet, to
> > give distributions and users a chance to patch.
>
> Thank you. I'm sorry you've had your moment somewhat spoiled.
>
> I include some notes for readers.
>
> --
>
> Please note that despite the commit title and contents, it is not
> exclusive to ptrace, and ptrace restriction mechanisms will not help
> here.
>
> As for mitigations: I don't think there are any real ones.
>
> Some ideas:
> * Block pidfd_getfd. I don't think it's actually used that heavily and
>   there's often fallbacks for older kernels when it is.
>
> * You could remove the world-executable bit from ssh-keysign
>   but this is *not* the only binary affected, and this is a very weak
>   mitigation indeed __only for the PoC__.
>
> The patch from Linus applies cleanly down to 6.6 or so. For 6.1 (IIRC),
> there was a trivial conflict (attached for convenience).
>
> For 5.10, a prerequisite commit is handy:
> 5bc78502322a5e4eef3f1b2a2813751dc6434143, then apply the 6.1 version.

I'm not 100% certian, but setting restrictive kernel.yama.ptrace_scope
might as well serve as temporary workaround. Can you confirm?

Regards,
Salvatore