* [PATCH 7.0.y] ptrace: slightly saner 'get_dumpable()' logic
@ 2026-05-15 7:33 Uwe Kleine-König
2026-05-15 7:39 ` Uwe Kleine-König
0 siblings, 1 reply; 4+ messages in thread
From: Uwe Kleine-König @ 2026-05-15 7:33 UTC (permalink / raw)
To: stable; +Cc: Linus Torvalds, Qualys Security Advisory, Oleg Nesterov,
Kees Cook
From: Linus Torvalds <torvalds@linux-foundation.org>
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>
---
Hello,
this fix seems to be relevant for backporting but lacks a Cc: for stable
and didn't appear on the list yet. I assume that the stable team has
this on their radar, but just to be sure and maybe to make more people
aware, here is an official backport.
It applies fine to 6.18.y and 6.12.y. Will send backports to 6.6.y and
older in a moment.
Best regards
Uwe
include/linux/sched.h | 3 +++
kernel/exit.c | 1 +
kernel/ptrace.c | 22 ++++++++++++++++------
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 007a0b61856d..d41e7a8f9c85 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -998,6 +998,9 @@ struct task_struct {
unsigned sched_rt_mutex:1;
#endif
+ /* Save user-dumpable when mm goes away */
+ unsigned user_dumpable:1;
+
/* Bit to tell TOMOYO we're in execve(): */
unsigned in_execve:1;
unsigned in_iowait:1;
diff --git a/kernel/exit.c b/kernel/exit.c
index ede3117fa7d4..bbb44fd3ffba 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -571,6 +571,7 @@ static void exit_mm(void)
*/
smp_mb__after_spinlock();
local_irq_disable();
+ current->user_dumpable = (get_dumpable(mm) == SUID_DUMP_USER);
current->mm = NULL;
membarrier_update_current_mm(NULL);
enter_lazy_tlb(mm, current);
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 392ec2f75f01..0e3ab697cff5 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -272,11 +272,24 @@ static bool ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
return ns_capable(ns, CAP_SYS_PTRACE);
}
+static bool task_still_dumpable(struct task_struct *task, unsigned int mode)
+{
+ struct mm_struct *mm = task->mm;
+ if (mm) {
+ if (get_dumpable(mm) == SUID_DUMP_USER)
+ return true;
+ return ptrace_has_cap(mm->user_ns, mode);
+ }
+
+ if (task->user_dumpable)
+ return true;
+ return ptrace_has_cap(&init_user_ns, mode);
+}
+
/* Returns 0 on success, -errno on denial. */
static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
{
const struct cred *cred = current_cred(), *tcred;
- struct mm_struct *mm;
kuid_t caller_uid;
kgid_t caller_gid;
@@ -337,11 +350,8 @@ static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
* Pairs with a write barrier in commit_creds().
*/
smp_rmb();
- mm = task->mm;
- if (mm &&
- ((get_dumpable(mm) != SUID_DUMP_USER) &&
- !ptrace_has_cap(mm->user_ns, mode)))
- return -EPERM;
+ if (!task_still_dumpable(task, mode))
+ return -EPERM;
return security_ptrace_access_check(task, mode);
}
base-commit: 5d83f95062a860326fd9c69a9d7a1f01063270c1
--
2.47.3
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH 7.0.y] ptrace: slightly saner 'get_dumpable()' logic
2026-05-15 7:33 [PATCH 7.0.y] ptrace: slightly saner 'get_dumpable()' logic Uwe Kleine-König
@ 2026-05-15 7:39 ` Uwe Kleine-König
2026-05-15 8:06 ` Greg KH
0 siblings, 1 reply; 4+ messages in thread
From: Uwe Kleine-König @ 2026-05-15 7:39 UTC (permalink / raw)
To: stable; +Cc: Linus Torvalds, Qualys Security Advisory, Oleg Nesterov,
Kees Cook
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 7.0.y] ptrace: slightly saner 'get_dumpable()' logic
2026-05-15 7:39 ` Uwe Kleine-König
@ 2026-05-15 8:06 ` Greg KH
2026-05-15 8:23 ` Greg KH
0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2026-05-15 8:06 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: stable, Linus Torvalds, Qualys Security Advisory, Oleg Nesterov,
Kees Cook
On Fri, May 15, 2026 at 09:39:38AM +0200, Uwe Kleine-König wrote:
> 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.
I've already queued this up to all of the stable queues a few hours ago.
Note, the older queues require some manual rework, which I already did.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 7.0.y] ptrace: slightly saner 'get_dumpable()' logic
2026-05-15 8:06 ` Greg KH
@ 2026-05-15 8:23 ` Greg KH
0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2026-05-15 8:23 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: stable, Linus Torvalds, Qualys Security Advisory, Oleg Nesterov,
Kees Cook
On Fri, May 15, 2026 at 10:06:35AM +0200, Greg KH wrote:
> On Fri, May 15, 2026 at 09:39:38AM +0200, Uwe Kleine-König wrote:
> > 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.
>
> I've already queued this up to all of the stable queues a few hours ago.
>
> Note, the older queues require some manual rework, which I already did.
Ah, I see you did that as well, sorry for the extra work :(
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-05-15 8:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-15 7:33 [PATCH 7.0.y] ptrace: slightly saner 'get_dumpable()' logic Uwe Kleine-König
2026-05-15 7:39 ` Uwe Kleine-König
2026-05-15 8:06 ` Greg KH
2026-05-15 8:23 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox