public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
* + kernel-fork-validate-exit_signal-in-clone-syscall.patch added to mm-nonmm-unstable branch
@ 2026-03-08 21:31 Andrew Morton
  2026-03-09  9:58 ` Oleg Nesterov
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2026-03-08 21:31 UTC (permalink / raw)
  To: mm-commits, vschneid, vincent.guittot, surenb, stable, rppt,
	rostedt, peterz, oleg, mingo, mhocko, mgorman, lorenzo.stoakes,
	liam.howlett, kees, Kartikey406, juri.lelli, dietmar.eggemann,
	david, bsegall, brauner, kartikey406, akpm


The patch titled
     Subject: kernel/fork: validate exit_signal in clone() syscall
has been added to the -mm mm-nonmm-unstable branch.  Its filename is
     kernel-fork-validate-exit_signal-in-clone-syscall.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kernel-fork-validate-exit_signal-in-clone-syscall.patch

This patch will later appear in the mm-nonmm-unstable branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: Deepanshu Kartikey <kartikey406@gmail.com>
Subject: kernel/fork: validate exit_signal in clone() syscall
Date: Sat, 7 Mar 2026 12:12:02 +0530

When a child process exits, it sends exit_signal to its parent via
do_notify_parent().  The clone() syscall constructs exit_signal as:

  (lower_32_bits(clone_flags) & CSIGNAL)

CSIGNAL is 0xff, so values in the range 65-255 are possible.  However,
valid_signal() only accepts signals up to _NSIG (64 on x86_64), causing a
WARN_ON in do_notify_parent() when the process exits:

  WARNING: kernel/signal.c:2174 do_notify_parent+0xc7e/0xd70

The syzkaller reproducer triggers this by calling clone() with flags=0x80,
resulting in exit_signal = (0x80 & CSIGNAL) = 128, which exceeds _NSIG and
is not a valid signal.

The comment above kernel_clone() states that callers are expected to
validate exit_signal.  clone3() correctly does this:

  if (unlikely((args.exit_signal & ~((u64)CSIGNAL)) ||
               !valid_signal(args.exit_signal)))
          return -EINVAL;

The clone() syscall has no such check.  Add the missing valid_signal()
check to clone(), consistent with the existing validation in clone3().

Link: https://lkml.kernel.org/r/20260307064202.353405-1-kartikey406@gmail.com
Fixes: 3f2c788a1314 ("fork: prevent accidental access to clone3 features")
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
Reported-by: syzbot+bbe6b99feefc3a0842de@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=bbe6b99feefc3a0842de
Tested-by: syzbot+bbe6b99feefc3a0842de@syzkaller.appspotmail.com
Cc: Ben Segall <bsegall@google.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 kernel/fork.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/fork.c~kernel-fork-validate-exit_signal-in-clone-syscall
+++ a/kernel/fork.c
@@ -2800,7 +2800,8 @@ SYSCALL_DEFINE5(clone, unsigned long, cl
 		.stack		= newsp,
 		.tls		= tls,
 	};
-
+	if (!valid_signal(args.exit_signal))
+		return -EINVAL;
 	return kernel_clone(&args);
 }
 #endif
_

Patches currently in -mm which might be from kartikey406@gmail.com are

kernel-fork-validate-exit_signal-in-clone-syscall.patch


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: + kernel-fork-validate-exit_signal-in-clone-syscall.patch added to mm-nonmm-unstable branch
  2026-03-08 21:31 + kernel-fork-validate-exit_signal-in-clone-syscall.patch added to mm-nonmm-unstable branch Andrew Morton
@ 2026-03-09  9:58 ` Oleg Nesterov
  2026-03-09 10:38   ` Deepanshu Kartikey
  0 siblings, 1 reply; 4+ messages in thread
From: Oleg Nesterov @ 2026-03-09  9:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: mm-commits, vschneid, vincent.guittot, surenb, stable, rppt,
	rostedt, peterz, mingo, mhocko, mgorman, lorenzo.stoakes,
	liam.howlett, kees, Kartikey406, juri.lelli, dietmar.eggemann,
	david, bsegall, brauner

On 03/08, Andrew Morton wrote:
>
> From: Deepanshu Kartikey <kartikey406@gmail.com>
> Subject: kernel/fork: validate exit_signal in clone() syscall
> Date: Sat, 7 Mar 2026 12:12:02 +0530
>
> When a child process exits, it sends exit_signal to its parent via
> do_notify_parent().  The clone() syscall constructs exit_signal as:
>
>   (lower_32_bits(clone_flags) & CSIGNAL)
>
> CSIGNAL is 0xff, so values in the range 65-255 are possible.  However,
> valid_signal() only accepts signals up to _NSIG (64 on x86_64), causing a
> WARN_ON in do_notify_parent() when the process exits:
>
>   WARNING: kernel/signal.c:2174 do_notify_parent+0xc7e/0xd70

Aaah. Thanks Deepanshu! My bad, please see below.

> The comment above kernel_clone() states that callers are expected to
> validate exit_signal.

Yes, and man 2 clone says:

      The termination signal is specified in the low byte of flags (clone()) or in cl_args.exit_signal (clone3()).
      If no signal (i.e., zero) is specified, then the parent process is not signaled when the child terminates.

it doesn't document that nonzero non-valid signal acts as .exit_signal == 0.

> --- a/kernel/fork.c~kernel-fork-validate-exit_signal-in-clone-syscall
> +++ a/kernel/fork.c
> @@ -2800,7 +2800,8 @@ SYSCALL_DEFINE5(clone, unsigned long, cl
>  		.stack		= newsp,
>  		.tls		= tls,
>  	};
> -
> +	if (!valid_signal(args.exit_signal))
> +		return -EINVAL;
>  	return kernel_clone(&args);

Well, kernel_clone() has more users which doesn't validate .exit_signal,
say sys_ia32_clone().

we need to move the valid_signal() check from copy_clone_args_from_user()
to kernel_clone() or copy_process()...

So. This should fix my

	[PATCH] do_notify_parent: sanitize the valid_signal() checks
	https://lore.kernel.org/all/aZsfg0Y055yuAvsq@redhat.com/

do_notify_parent-sanitize-the-valid_signal-checks.patch in -mm tree.

Somehow I was very sure that copy_process() paths already have the valid_signal()
check but my memory fooled me.

But this is a user visible change which can cause other bug reports...
Perhaps we should revert do_notify_parent-sanitize-the-valid_signal-checks.patch
and this patch?

Even if I think that the new valid_signal() check "fixes" the undocumented
behaviour, unlikely there is a sane application which passes non-valid exit
signal to sys_clone(). But who knows...

Oleg.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: + kernel-fork-validate-exit_signal-in-clone-syscall.patch added to mm-nonmm-unstable branch
  2026-03-09  9:58 ` Oleg Nesterov
@ 2026-03-09 10:38   ` Deepanshu Kartikey
  2026-03-09 10:47     ` Oleg Nesterov
  0 siblings, 1 reply; 4+ messages in thread
From: Deepanshu Kartikey @ 2026-03-09 10:38 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Andrew Morton, mm-commits, vschneid, vincent.guittot, surenb,
	stable, rppt, rostedt, peterz, mingo, mhocko, mgorman,
	lorenzo.stoakes, liam.howlett, kees, juri.lelli, dietmar.eggemann,
	david, bsegall, brauner

On Mon, Mar 9, 2026 at 3:28 PM Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 03/08, Andrew Morton wrote:
> >
> > From: Deepanshu Kartikey <kartikey406@gmail.com>
> > Subject: kernel/fork: validate exit_signal in clone() syscall
> > Date: Sat, 7 Mar 2026 12:12:02 +0530
> >
> > When a child process exits, it sends exit_signal to its parent via
> > do_notify_parent().  The clone() syscall constructs exit_signal as:
> >
> >   (lower_32_bits(clone_flags) & CSIGNAL)
> >
> > CSIGNAL is 0xff, so values in the range 65-255 are possible.  However,
> > valid_signal() only accepts signals up to _NSIG (64 on x86_64), causing a
> > WARN_ON in do_notify_parent() when the process exits:
> >
> >   WARNING: kernel/signal.c:2174 do_notify_parent+0xc7e/0xd70
>
> Aaah. Thanks Deepanshu! My bad, please see below.
>
> > The comment above kernel_clone() states that callers are expected to
> > validate exit_signal.
>
> Yes, and man 2 clone says:
>
>       The termination signal is specified in the low byte of flags (clone()) or in cl_args.exit_signal (clone3()).
>       If no signal (i.e., zero) is specified, then the parent process is not signaled when the child terminates.
>
> it doesn't document that nonzero non-valid signal acts as .exit_signal == 0.
>
> > --- a/kernel/fork.c~kernel-fork-validate-exit_signal-in-clone-syscall
> > +++ a/kernel/fork.c
> > @@ -2800,7 +2800,8 @@ SYSCALL_DEFINE5(clone, unsigned long, cl
> >               .stack          = newsp,
> >               .tls            = tls,
> >       };
> > -
> > +     if (!valid_signal(args.exit_signal))
> > +             return -EINVAL;
> >       return kernel_clone(&args);
>
> Well, kernel_clone() has more users which doesn't validate .exit_signal,
> say sys_ia32_clone().
>
> we need to move the valid_signal() check from copy_clone_args_from_user()
> to kernel_clone() or copy_process()...
>
> So. This should fix my
>
>         [PATCH] do_notify_parent: sanitize the valid_signal() checks
>         https://lore.kernel.org/all/aZsfg0Y055yuAvsq@redhat.com/
>
> do_notify_parent-sanitize-the-valid_signal-checks.patch in -mm tree.
>
> Somehow I was very sure that copy_process() paths already have the valid_signal()
> check but my memory fooled me.
>
> But this is a user visible change which can cause other bug reports...
> Perhaps we should revert do_notify_parent-sanitize-the-valid_signal-checks.patch
> and this patch?
>
> Even if I think that the new valid_signal() check "fixes" the undocumented
> behaviour, unlikely there is a sane application which passes non-valid exit
> signal to sys_clone(). But who knows...
>
> Oleg.
>

Hi Oleg,

Thank you for the review.

You are correct that fixing only the clone() syscall is incomplete.
sys_ia32_clone() and other kernel_clone() callers would remain
unprotected. I will send a v2 with the valid_signal() check moved
to kernel_clone() to cover all callers.

Regarding your do_notify_parent patch — since v2 will fix the root
cause at kernel_clone(), your patch in the -mm tree can be dropped.

Regards,
Deepanshu Kartikey

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: + kernel-fork-validate-exit_signal-in-clone-syscall.patch added to mm-nonmm-unstable branch
  2026-03-09 10:38   ` Deepanshu Kartikey
@ 2026-03-09 10:47     ` Oleg Nesterov
  0 siblings, 0 replies; 4+ messages in thread
From: Oleg Nesterov @ 2026-03-09 10:47 UTC (permalink / raw)
  To: Deepanshu Kartikey
  Cc: Andrew Morton, mm-commits, vschneid, vincent.guittot, surenb,
	stable, rppt, rostedt, peterz, mingo, mhocko, mgorman,
	lorenzo.stoakes, liam.howlett, kees, juri.lelli, dietmar.eggemann,
	david, bsegall, brauner

On 03/09, Deepanshu Kartikey wrote:
>
> > Well, kernel_clone() has more users which doesn't validate .exit_signal,
> > say sys_ia32_clone().
> >
> > we need to move the valid_signal() check from copy_clone_args_from_user()
> > to kernel_clone() or copy_process()...
> >
> > So. This should fix my
> >
> >         [PATCH] do_notify_parent: sanitize the valid_signal() checks
> >         https://lore.kernel.org/all/aZsfg0Y055yuAvsq@redhat.com/
> >
> > do_notify_parent-sanitize-the-valid_signal-checks.patch in -mm tree.
> >
> > Somehow I was very sure that copy_process() paths already have the valid_signal()
> > check but my memory fooled me.
> >
> > But this is a user visible change which can cause other bug reports...
> > Perhaps we should revert do_notify_parent-sanitize-the-valid_signal-checks.patch
> > and this patch?
> >
> > Even if I think that the new valid_signal() check "fixes" the undocumented
> > behaviour, unlikely there is a sane application which passes non-valid exit
> > signal to sys_clone(). But who knows...
> >
> > Oleg.
> >
>
> Hi Oleg,
>
> Thank you for the review.
>
> You are correct that fixing only the clone() syscall is incomplete.
> sys_ia32_clone() and other kernel_clone() callers would remain
> unprotected. I will send a v2 with the valid_signal() check moved
> to kernel_clone() to cover all callers.
>
> Regarding your do_notify_parent patch — since v2 will fix the root
> cause at kernel_clone(), your patch in the -mm tree can be dropped.

Well. my patch can be dropped with or without your v2. It is just
a cleanup and I still think it is a good cleanup...

But without your fix it is wrong. From the changelog:

	The "sig" argument of do_notify_parent() must always be valid

this is not true because (contrary to what I thought) sys_clone doesn't
validate exit_signal. The

	WARN_ON_ONCE(!valid_signal(sig))

added by that patch allowed to notice the problem you are trying to fix.

But again, this (your patch) is a user-visible change, and I am worried
even if I think this change is good.

Oleg.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-03-09 10:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-08 21:31 + kernel-fork-validate-exit_signal-in-clone-syscall.patch added to mm-nonmm-unstable branch Andrew Morton
2026-03-09  9:58 ` Oleg Nesterov
2026-03-09 10:38   ` Deepanshu Kartikey
2026-03-09 10:47     ` Oleg Nesterov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox