Re: [PATCH 7.0.y] ptrace: slightly saner 'get_dumpable()' logic

["Uwe Kleine-König" <ukleinek@debian.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1677 bytes --]

Hello,


On 2026-05-15 09:33, Uwe Kleine-König wrote:
> From: Linus Torvalds <torvalds@linux-foundation.org>

oops, I forgot:

	commit 31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a upstream.

here.

> The 'dumpability' of a task is fundamentally about the memory image of
> the task - the concept comes from whether it can core dump or not - and
> makes no sense when you don't have an associated mm.
> 
> And almost all users do in fact use it only for the case where the task
> has a mm pointer.
> 
> But we have one odd special case: ptrace_may_access() uses 'dumpable' to
> check various other things entirely independently of the MM (typically
> explicitly using flags like PTRACE_MODE_READ_FSCREDS).  Including for
> threads that no longer have a VM (and maybe never did, like most kernel
> threads).
> 
> It's not what this flag was designed for, but it is what it is.
> 
> The ptrace code does check that the uid/gid matches, so you do have to
> be uid-0 to see kernel thread details, but this means that the
> traditional "drop capabilities" model doesn't make any difference for
> this all.
> 
> Make it all make a *bit* more sense by saying that if you don't have a
> MM pointer, we'll use a cached "last dumpability" flag if the thread
> ever had a MM (it will be zero for kernel threads since it is never
> set), and require a proper CAP_SYS_PTRACE capability to override.
> 
> Reported-by: Qualys Security Advisory <qsa@qualys.com>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Kees Cook <kees@kernel.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Uwe Kleine-König <ukleinek@debian.org>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]