* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-22 12:31 FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree gregkh
@ 2021-11-23 15:08 ` Kyle Huey
2021-11-23 17:29 ` Thomas Backlund
2021-11-24 1:33 ` Kyle Huey
2 siblings, 0 replies; 13+ messages in thread
From: Kyle Huey @ 2021-11-23 15:08 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Kees Cook, Kyle Huey, Oliver Sang, Linus Torvalds, stable,
Robert O'Callahan, gregkh
Eric, are you going to take care of this?
- Kyle
On Mon, Nov 22, 2021 at 4:31 AM <gregkh@linuxfoundation.org> wrote:
>
>
> The patch below does not apply to the 5.15-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> thanks,
>
> greg k-h
>
> ------------------ original commit in Linus's tree ------------------
>
> From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Thu, 18 Nov 2021 11:11:13 -0600
> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>
> Recently to prevent issues with SECCOMP_RET_KILL and similar signals
> being changed before they are delivered SA_IMMUTABLE was added.
>
> Unfortunately this broke debuggers[1][2] which reasonably expect to be
> able to trap synchronous SIGTRAP and SIGSEGV even when the target
> process is not configured to handle those signals.
>
> Update force_sig_to_task to support both the case when we can allow
> the debugger to intercept and possibly ignore the signal and the case
> when it is not safe to let userspace know about the signal until the
> process has exited.
>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Reported-by: Kyle Huey <me@kylehuey.com>
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Cc: stable@vger.kernel.org
> [1] https://lkml.kernel.org/r/CAP045AoMY4xf8aC_4QU_-j7obuEPYgTcnQQP3Yxk=2X90jtpjw@mail.gmail.com
> [2] https://lkml.kernel.org/r/20211117150258.GB5403@xsang-OptiPlex-9020
> Fixes: 00b06da29cf9 ("signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed")
> Link: https://lkml.kernel.org/r/877dd5qfw5.fsf_-_@email.froward.int.ebiederm.org
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Tested-by: Kees Cook <keescook@chromium.org>
> Tested-by: Kyle Huey <khuey@kylehuey.com>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 7c4b7ae714d4..7815e1bbeddc 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1298,6 +1298,12 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p
> return ret;
> }
>
> +enum sig_handler {
> + HANDLER_CURRENT, /* If reachable use the current handler */
> + HANDLER_SIG_DFL, /* Always use SIG_DFL handler semantics */
> + HANDLER_EXIT, /* Only visible as the process exit code */
> +};
> +
> /*
> * Force a signal that the process can't ignore: if necessary
> * we unblock the signal and change any SIG_IGN to SIG_DFL.
> @@ -1310,7 +1316,8 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p
> * that is why we also clear SIGNAL_UNKILLABLE.
> */
> static int
> -force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool sigdfl)
> +force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t,
> + enum sig_handler handler)
> {
> unsigned long int flags;
> int ret, blocked, ignored;
> @@ -1321,9 +1328,10 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool
> action = &t->sighand->action[sig-1];
> ignored = action->sa.sa_handler == SIG_IGN;
> blocked = sigismember(&t->blocked, sig);
> - if (blocked || ignored || sigdfl) {
> + if (blocked || ignored || (handler != HANDLER_CURRENT)) {
> action->sa.sa_handler = SIG_DFL;
> - action->sa.sa_flags |= SA_IMMUTABLE;
> + if (handler == HANDLER_EXIT)
> + action->sa.sa_flags |= SA_IMMUTABLE;
> if (blocked) {
> sigdelset(&t->blocked, sig);
> recalc_sigpending_and_wake(t);
> @@ -1343,7 +1351,7 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool
>
> int force_sig_info(struct kernel_siginfo *info)
> {
> - return force_sig_info_to_task(info, current, false);
> + return force_sig_info_to_task(info, current, HANDLER_CURRENT);
> }
>
> /*
> @@ -1660,7 +1668,7 @@ void force_fatal_sig(int sig)
> info.si_code = SI_KERNEL;
> info.si_pid = 0;
> info.si_uid = 0;
> - force_sig_info_to_task(&info, current, true);
> + force_sig_info_to_task(&info, current, HANDLER_SIG_DFL);
> }
>
> /*
> @@ -1693,7 +1701,7 @@ int force_sig_fault_to_task(int sig, int code, void __user *addr
> info.si_flags = flags;
> info.si_isr = isr;
> #endif
> - return force_sig_info_to_task(&info, t, false);
> + return force_sig_info_to_task(&info, t, HANDLER_CURRENT);
> }
>
> int force_sig_fault(int sig, int code, void __user *addr
> @@ -1813,7 +1821,8 @@ int force_sig_seccomp(int syscall, int reason, bool force_coredump)
> info.si_errno = reason;
> info.si_arch = syscall_get_arch(current);
> info.si_syscall = syscall;
> - return force_sig_info_to_task(&info, current, force_coredump);
> + return force_sig_info_to_task(&info, current,
> + force_coredump ? HANDLER_EXIT : HANDLER_CURRENT);
> }
>
> /* For the crazy architectures that include trap information in
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-22 12:31 FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree gregkh
2021-11-23 15:08 ` Kyle Huey
@ 2021-11-23 17:29 ` Thomas Backlund
2021-11-23 18:12 ` Greg KH
2021-11-24 1:33 ` Kyle Huey
2 siblings, 1 reply; 13+ messages in thread
From: Thomas Backlund @ 2021-11-23 17:29 UTC (permalink / raw)
To: gregkh, ebiederm, keescook, khuey, me, oliver.sang, torvalds; +Cc: stable
Den 2021-11-22 kl. 14:31, skrev gregkh@linuxfoundation.org:
>
> The patch below does not apply to the 5.15-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> thanks,
>
> greg k-h
It will apply if you add this one first:
From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:43:59 -0500
Subject: [PATCH] signal: Implement force_fatal_sig
and if the other patch for signal that has similar description should
land in 5.15:
From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Thu, 18 Nov 2021 14:23:21 -0600
Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig
when in doubt
then the list is looks something like:
From 941edc5bf174b67f94db19817cbeab0a93e0c32a Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:44:00 -0500
Subject: [PATCH] exit/syscall_user_dispatch: Send ordinary signals on
failure
From 83a1f27ad773b1d8f0460d3a676114c7651918cc Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:43:53 -0500
Subject: [PATCH] signal/powerpc: On swapcontext failure force SIGSEGV
From 9bc508cf0791c8e5a37696de1a046d746fcbd9d8 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:43:57 -0500
Subject: [PATCH] signal/s390: Use force_sigsegv in default_trap_handler
From c317d306d55079525c9610267fdaf3a8a6d2f08b Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:44:01 -0500
Subject: [PATCH] signal/sparc32: Exit with a fatal signal when
try_to_clear_window_buffer fails
From 086ec444f86660e103de8945d0dcae9b67132ac9 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:44:02 -0500
Subject: [PATCH] signal/sparc32: In setup_rt_frame and setup_fram use
force_fatal_sig
From 1fbd60df8a852d9c55de8cd3621899cf4c72a5b7 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:43:56 -0500
Subject: [PATCH] signal/vm86_32: Properly send SIGSEGV when the vm86
state cannot be saved.
From 695dd0d634df8903e5ead8aa08d326f63b23368a Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:44:03 -0500
Subject: [PATCH] signal/x86: In emulate_vsyscall force a signal instead
of calling do_exit
From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Wed, 20 Oct 2021 12:43:59 -0500
Subject: [PATCH] signal: Implement force_fatal_sig
From e21294a7aaae32c5d7154b187113a04db5852e37 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Mon, 25 Oct 2021 10:50:57 -0500
Subject: [PATCH] signal: Replace force_sigsegv(SIGSEGV) with
force_fatal_sig(SIGSEGV)
From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Thu, 18 Nov 2021 11:11:13 -0600
Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Thu, 18 Nov 2021 14:23:21 -0600
Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig
when in doubt
Applying them in listed order on top of 5.14.4 and builds/runs on i586,
x86_64, armv7hl, aarch64
--
Thomas
>
> ------------------ original commit in Linus's tree ------------------
>
> From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Thu, 18 Nov 2021 11:11:13 -0600
> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>
> Recently to prevent issues with SECCOMP_RET_KILL and similar signals
> being changed before they are delivered SA_IMMUTABLE was added.
>
> Unfortunately this broke debuggers[1][2] which reasonably expect to be
> able to trap synchronous SIGTRAP and SIGSEGV even when the target
> process is not configured to handle those signals.
>
> Update force_sig_to_task to support both the case when we can allow
> the debugger to intercept and possibly ignore the signal and the case
> when it is not safe to let userspace know about the signal until the
> process has exited.
>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Reported-by: Kyle Huey <me@kylehuey.com>
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Cc: stable@vger.kernel.org
> [1] https://lkml.kernel.org/r/CAP045AoMY4xf8aC_4QU_-j7obuEPYgTcnQQP3Yxk=2X90jtpjw@mail.gmail.com
> [2] https://lkml.kernel.org/r/20211117150258.GB5403@xsang-OptiPlex-9020
> Fixes: 00b06da29cf9 ("signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed")
> Link: https://lkml.kernel.org/r/877dd5qfw5.fsf_-_@email.froward.int.ebiederm.org
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Tested-by: Kees Cook <keescook@chromium.org>
> Tested-by: Kyle Huey <khuey@kylehuey.com>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 7c4b7ae714d4..7815e1bbeddc 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1298,6 +1298,12 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p
> return ret;
> }
>
> +enum sig_handler {
> + HANDLER_CURRENT, /* If reachable use the current handler */
> + HANDLER_SIG_DFL, /* Always use SIG_DFL handler semantics */
> + HANDLER_EXIT, /* Only visible as the process exit code */
> +};
> +
> /*
> * Force a signal that the process can't ignore: if necessary
> * we unblock the signal and change any SIG_IGN to SIG_DFL.
> @@ -1310,7 +1316,8 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p
> * that is why we also clear SIGNAL_UNKILLABLE.
> */
> static int
> -force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool sigdfl)
> +force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t,
> + enum sig_handler handler)
> {
> unsigned long int flags;
> int ret, blocked, ignored;
> @@ -1321,9 +1328,10 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool
> action = &t->sighand->action[sig-1];
> ignored = action->sa.sa_handler == SIG_IGN;
> blocked = sigismember(&t->blocked, sig);
> - if (blocked || ignored || sigdfl) {
> + if (blocked || ignored || (handler != HANDLER_CURRENT)) {
> action->sa.sa_handler = SIG_DFL;
> - action->sa.sa_flags |= SA_IMMUTABLE;
> + if (handler == HANDLER_EXIT)
> + action->sa.sa_flags |= SA_IMMUTABLE;
> if (blocked) {
> sigdelset(&t->blocked, sig);
> recalc_sigpending_and_wake(t);
> @@ -1343,7 +1351,7 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool
>
> int force_sig_info(struct kernel_siginfo *info)
> {
> - return force_sig_info_to_task(info, current, false);
> + return force_sig_info_to_task(info, current, HANDLER_CURRENT);
> }
>
> /*
> @@ -1660,7 +1668,7 @@ void force_fatal_sig(int sig)
> info.si_code = SI_KERNEL;
> info.si_pid = 0;
> info.si_uid = 0;
> - force_sig_info_to_task(&info, current, true);
> + force_sig_info_to_task(&info, current, HANDLER_SIG_DFL);
> }
>
> /*
> @@ -1693,7 +1701,7 @@ int force_sig_fault_to_task(int sig, int code, void __user *addr
> info.si_flags = flags;
> info.si_isr = isr;
> #endif
> - return force_sig_info_to_task(&info, t, false);
> + return force_sig_info_to_task(&info, t, HANDLER_CURRENT);
> }
>
> int force_sig_fault(int sig, int code, void __user *addr
> @@ -1813,7 +1821,8 @@ int force_sig_seccomp(int syscall, int reason, bool force_coredump)
> info.si_errno = reason;
> info.si_arch = syscall_get_arch(current);
> info.si_syscall = syscall;
> - return force_sig_info_to_task(&info, current, force_coredump);
> + return force_sig_info_to_task(&info, current,
> + force_coredump ? HANDLER_EXIT : HANDLER_CURRENT);
> }
>
> /* For the crazy architectures that include trap information in
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-23 17:29 ` Thomas Backlund
@ 2021-11-23 18:12 ` Greg KH
2021-11-23 19:24 ` Eric W. Biederman
0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2021-11-23 18:12 UTC (permalink / raw)
To: Thomas Backlund
Cc: ebiederm, keescook, khuey, me, oliver.sang, torvalds, stable
On Tue, Nov 23, 2021 at 07:29:43PM +0200, Thomas Backlund wrote:
> Den 2021-11-22 kl. 14:31, skrev gregkh@linuxfoundation.org:
> >
> > The patch below does not apply to the 5.15-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> >
> > thanks,
> >
> > greg k-h
>
>
> It will apply if you add this one first:
>
> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:43:59 -0500
> Subject: [PATCH] signal: Implement force_fatal_sig
>
>
>
>
> and if the other patch for signal that has similar description should land
> in 5.15:
>
> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Thu, 18 Nov 2021 14:23:21 -0600
> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
> doubt
>
>
>
> then the list is looks something like:
>
>
> From 941edc5bf174b67f94db19817cbeab0a93e0c32a Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:44:00 -0500
> Subject: [PATCH] exit/syscall_user_dispatch: Send ordinary signals on
> failure
>
> From 83a1f27ad773b1d8f0460d3a676114c7651918cc Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:43:53 -0500
> Subject: [PATCH] signal/powerpc: On swapcontext failure force SIGSEGV
>
> From 9bc508cf0791c8e5a37696de1a046d746fcbd9d8 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:43:57 -0500
> Subject: [PATCH] signal/s390: Use force_sigsegv in default_trap_handler
>
> From c317d306d55079525c9610267fdaf3a8a6d2f08b Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:44:01 -0500
> Subject: [PATCH] signal/sparc32: Exit with a fatal signal when
> try_to_clear_window_buffer fails
>
> From 086ec444f86660e103de8945d0dcae9b67132ac9 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:44:02 -0500
> Subject: [PATCH] signal/sparc32: In setup_rt_frame and setup_fram use
> force_fatal_sig
>
> From 1fbd60df8a852d9c55de8cd3621899cf4c72a5b7 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:43:56 -0500
> Subject: [PATCH] signal/vm86_32: Properly send SIGSEGV when the vm86 state
> cannot be saved.
>
> From 695dd0d634df8903e5ead8aa08d326f63b23368a Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:44:03 -0500
> Subject: [PATCH] signal/x86: In emulate_vsyscall force a signal instead of
> calling do_exit
>
> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Wed, 20 Oct 2021 12:43:59 -0500
> Subject: [PATCH] signal: Implement force_fatal_sig
>
> From e21294a7aaae32c5d7154b187113a04db5852e37 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Mon, 25 Oct 2021 10:50:57 -0500
> Subject: [PATCH] signal: Replace force_sigsegv(SIGSEGV) with
> force_fatal_sig(SIGSEGV)
>
> From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Thu, 18 Nov 2021 11:11:13 -0600
> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>
> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Thu, 18 Nov 2021 14:23:21 -0600
> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
> doubt
>
>
>
> Applying them in listed order on top of 5.14.4 and builds/runs on i586,
> x86_64, armv7hl, aarch64
That series list is crazy, let me go try it and see what blows up! :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-23 18:12 ` Greg KH
@ 2021-11-23 19:24 ` Eric W. Biederman
2021-11-23 20:00 ` Eric W. Biederman
2021-11-23 20:00 ` Thomas Backlund
0 siblings, 2 replies; 13+ messages in thread
From: Eric W. Biederman @ 2021-11-23 19:24 UTC (permalink / raw)
To: Greg KH
Cc: Thomas Backlund, keescook, khuey, me, oliver.sang, torvalds, stable
Greg KH <gregkh@linuxfoundation.org> writes:
> On Tue, Nov 23, 2021 at 07:29:43PM +0200, Thomas Backlund wrote:
>> Den 2021-11-22 kl. 14:31, skrev gregkh@linuxfoundation.org:
>> >
>> > The patch below does not apply to the 5.15-stable tree.
>> > If someone wants it applied there, or to any other stable or longterm
>> > tree, then please email the backport, including the original git commit
>> > id to <stable@vger.kernel.org>.
>> >
>> > thanks,
>> >
>> > greg k-h
>>
>>
>> It will apply if you add this one first:
>>
>> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>> Subject: [PATCH] signal: Implement force_fatal_sig
>>
>>
>>
>>
>> and if the other patch for signal that has similar description should land
>> in 5.15:
>>
>> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>> doubt
>>
>>
>>
>> then the list is looks something like:
>>
>>
>> From 941edc5bf174b67f94db19817cbeab0a93e0c32a Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:44:00 -0500
>> Subject: [PATCH] exit/syscall_user_dispatch: Send ordinary signals on
>> failure
>>
>> From 83a1f27ad773b1d8f0460d3a676114c7651918cc Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:43:53 -0500
>> Subject: [PATCH] signal/powerpc: On swapcontext failure force SIGSEGV
>>
>> From 9bc508cf0791c8e5a37696de1a046d746fcbd9d8 Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:43:57 -0500
>> Subject: [PATCH] signal/s390: Use force_sigsegv in default_trap_handler
>>
>> From c317d306d55079525c9610267fdaf3a8a6d2f08b Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:44:01 -0500
>> Subject: [PATCH] signal/sparc32: Exit with a fatal signal when
>> try_to_clear_window_buffer fails
>>
>> From 086ec444f86660e103de8945d0dcae9b67132ac9 Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:44:02 -0500
>> Subject: [PATCH] signal/sparc32: In setup_rt_frame and setup_fram use
>> force_fatal_sig
>>
>> From 1fbd60df8a852d9c55de8cd3621899cf4c72a5b7 Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:43:56 -0500
>> Subject: [PATCH] signal/vm86_32: Properly send SIGSEGV when the vm86 state
>> cannot be saved.
>>
>> From 695dd0d634df8903e5ead8aa08d326f63b23368a Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:44:03 -0500
>> Subject: [PATCH] signal/x86: In emulate_vsyscall force a signal instead of
>> calling do_exit
>>
>> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>> Subject: [PATCH] signal: Implement force_fatal_sig
>>
>> From e21294a7aaae32c5d7154b187113a04db5852e37 Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Mon, 25 Oct 2021 10:50:57 -0500
>> Subject: [PATCH] signal: Replace force_sigsegv(SIGSEGV) with
>> force_fatal_sig(SIGSEGV)
>>
>> From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Thu, 18 Nov 2021 11:11:13 -0600
>> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>>
>> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>> doubt
>>
>>
>>
>> Applying them in listed order on top of 5.14.4 and builds/runs on i586,
>> x86_64, armv7hl, aarch64
>
> That series list is crazy, let me go try it and see what blows up! :)
Maybe I am wrong but I think "Don't always set SA_IMMUTABLE for forced
signals" will apply if you drop the hunk modifying force_fatal_sig.
Then you don't need to backport all of the cleanups just the fix.
I will take a quick look and verify that.
Eric
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-23 19:24 ` Eric W. Biederman
@ 2021-11-23 20:00 ` Eric W. Biederman
2021-11-23 20:00 ` Thomas Backlund
1 sibling, 0 replies; 13+ messages in thread
From: Eric W. Biederman @ 2021-11-23 20:00 UTC (permalink / raw)
To: Greg KH
Cc: Thomas Backlund, keescook, khuey, me, oliver.sang, torvalds, stable
ebiederm@xmission.com (Eric W. Biederman) writes:
> Greg KH <gregkh@linuxfoundation.org> writes:
>
>> On Tue, Nov 23, 2021 at 07:29:43PM +0200, Thomas Backlund wrote:
>>> Den 2021-11-22 kl. 14:31, skrev gregkh@linuxfoundation.org:
>>> >
>>> > The patch below does not apply to the 5.15-stable tree.
>>> > If someone wants it applied there, or to any other stable or longterm
>>> > tree, then please email the backport, including the original git commit
>>> > id to <stable@vger.kernel.org>.
>>> >
>>> > thanks,
>>> >
>>> > greg k-h
>>>
>>>
>>> It will apply if you add this one first:
>>>
>>> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>>> Subject: [PATCH] signal: Implement force_fatal_sig
>>>
>>>
>>>
>>>
>>> and if the other patch for signal that has similar description should land
>>> in 5.15:
>>>
>>> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>>> doubt
>>>
>>>
>>>
>>> then the list is looks something like:
>>>
>>>
>>> From 941edc5bf174b67f94db19817cbeab0a93e0c32a Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:44:00 -0500
>>> Subject: [PATCH] exit/syscall_user_dispatch: Send ordinary signals on
>>> failure
>>>
>>> From 83a1f27ad773b1d8f0460d3a676114c7651918cc Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:53 -0500
>>> Subject: [PATCH] signal/powerpc: On swapcontext failure force SIGSEGV
>>>
>>> From 9bc508cf0791c8e5a37696de1a046d746fcbd9d8 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:57 -0500
>>> Subject: [PATCH] signal/s390: Use force_sigsegv in default_trap_handler
>>>
>>> From c317d306d55079525c9610267fdaf3a8a6d2f08b Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:44:01 -0500
>>> Subject: [PATCH] signal/sparc32: Exit with a fatal signal when
>>> try_to_clear_window_buffer fails
>>>
>>> From 086ec444f86660e103de8945d0dcae9b67132ac9 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:44:02 -0500
>>> Subject: [PATCH] signal/sparc32: In setup_rt_frame and setup_fram use
>>> force_fatal_sig
>>>
>>> From 1fbd60df8a852d9c55de8cd3621899cf4c72a5b7 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:56 -0500
>>> Subject: [PATCH] signal/vm86_32: Properly send SIGSEGV when the vm86 state
>>> cannot be saved.
>>>
>>> From 695dd0d634df8903e5ead8aa08d326f63b23368a Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:44:03 -0500
>>> Subject: [PATCH] signal/x86: In emulate_vsyscall force a signal instead of
>>> calling do_exit
>>>
>>> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>>> Subject: [PATCH] signal: Implement force_fatal_sig
>>>
>>> From e21294a7aaae32c5d7154b187113a04db5852e37 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Mon, 25 Oct 2021 10:50:57 -0500
>>> Subject: [PATCH] signal: Replace force_sigsegv(SIGSEGV) with
>>> force_fatal_sig(SIGSEGV)
>>>
>>> From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Thu, 18 Nov 2021 11:11:13 -0600
>>> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>>>
>>> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>>> doubt
>>>
>>>
>>>
>>> Applying them in listed order on top of 5.14.4 and builds/runs on i586,
>>> x86_64, armv7hl, aarch64
>>
>> That series list is crazy, let me go try it and see what blows up! :)
>
> Maybe I am wrong but I think "Don't always set SA_IMMUTABLE for forced
> signals" will apply if you drop the hunk modifying force_fatal_sig.
> Then you don't need to backport all of the cleanups just the fix.
>
> I will take a quick look and verify that.
Yes. I have just verified that if I drop the hunk for force_fatal_sig
which does not exit in 5.15 the patch applies cleanly and compiles
cleanly as well.
If you want to apply the whole series I will be flattered that you want
all of my cleanups in stable. There might be a point to it as intend to
keep cleaning things up, and code that is actually interesting to
backport might not backport if you don't backport all of my cleanups.
Personally I would say just apply a version without the force_fatal_sig
hunk and all should be well.
My patch with the force_fatal_sig hunk deleted after being applied to
v5.15.4 is below.
Eric
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Thu, 18 Nov 2021 11:11:13 -0600
Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
Recently to prevent issues with SECCOMP_RET_KILL and similar signals
being changed before they are delivered SA_IMMUTABLE was added.
Unfortunately this broke debuggers[1][2] which reasonably expect to be
able to trap synchronous SIGTRAP and SIGSEGV even when the target
process is not configured to handle those signals.
Update force_sig_to_task to support both the case when we can allow
the debugger to intercept and possibly ignore the signal and the case
when it is not safe to let userspace know about the signal until the
process has exited.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Kyle Huey <me@kylehuey.com>
Reported-by: kernel test robot <oliver.sang@intel.com>
Cc: stable@vger.kernel.org
[1] https://lkml.kernel.org/r/CAP045AoMY4xf8aC_4QU_-j7obuEPYgTcnQQP3Yxk=2X90jtpjw@mail.gmail.com
[2] https://lkml.kernel.org/r/20211117150258.GB5403@xsang-OptiPlex-9020
Fixes: 00b06da29cf9 ("signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed")
Link: https://lkml.kernel.org/r/877dd5qfw5.fsf_-_@email.froward.int.ebiederm.org
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Kees Cook <keescook@chromium.org>
Tested-by: Kyle Huey <khuey@kylehuey.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
kernel/signal.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index ef46309a9409..718bd2d2da7f 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1298,6 +1298,12 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p
return ret;
}
+enum sig_handler {
+ HANDLER_CURRENT, /* If reachable use the current handler */
+ HANDLER_SIG_DFL, /* Always use SIG_DFL handler semantics */
+ HANDLER_EXIT, /* Only visible as the process exit code */
+};
+
/*
* Force a signal that the process can't ignore: if necessary
* we unblock the signal and change any SIG_IGN to SIG_DFL.
@@ -1310,7 +1316,8 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p
* that is why we also clear SIGNAL_UNKILLABLE.
*/
static int
-force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool sigdfl)
+force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t,
+ enum sig_handler handler)
{
unsigned long int flags;
int ret, blocked, ignored;
@@ -1321,9 +1328,10 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool
action = &t->sighand->action[sig-1];
ignored = action->sa.sa_handler == SIG_IGN;
blocked = sigismember(&t->blocked, sig);
- if (blocked || ignored || sigdfl) {
+ if (blocked || ignored || (handler != HANDLER_CURRENT)) {
action->sa.sa_handler = SIG_DFL;
- action->sa.sa_flags |= SA_IMMUTABLE;
+ if (handler == HANDLER_EXIT)
+ action->sa.sa_flags |= SA_IMMUTABLE;
if (blocked) {
sigdelset(&t->blocked, sig);
recalc_sigpending_and_wake(t);
@@ -1343,7 +1351,7 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool
int force_sig_info(struct kernel_siginfo *info)
{
- return force_sig_info_to_task(info, current, false);
+ return force_sig_info_to_task(info, current, HANDLER_CURRENT);
}
/*
@@ -1685,7 +1693,7 @@ int force_sig_fault_to_task(int sig, int code, void __user *addr
info.si_flags = flags;
info.si_isr = isr;
#endif
- return force_sig_info_to_task(&info, t, false);
+ return force_sig_info_to_task(&info, t, HANDLER_CURRENT);
}
int force_sig_fault(int sig, int code, void __user *addr
@@ -1805,7 +1813,8 @@ int force_sig_seccomp(int syscall, int reason, bool force_coredump)
info.si_errno = reason;
info.si_arch = syscall_get_arch(current);
info.si_syscall = syscall;
- return force_sig_info_to_task(&info, current, force_coredump);
+ return force_sig_info_to_task(&info, current,
+ force_coredump ? HANDLER_EXIT : HANDLER_CURRENT);
}
/* For the crazy architectures that include trap information in
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-23 19:24 ` Eric W. Biederman
2021-11-23 20:00 ` Eric W. Biederman
@ 2021-11-23 20:00 ` Thomas Backlund
2021-11-23 21:41 ` Eric W. Biederman
1 sibling, 1 reply; 13+ messages in thread
From: Thomas Backlund @ 2021-11-23 20:00 UTC (permalink / raw)
To: ebiederm, Greg KH
Cc: Thomas Backlund, keescook, khuey, me, oliver.sang, torvalds, stable
Den 2021-11-23 kl. 21:24, skrev ebiederm@xmission.com:
> Greg KH <gregkh@linuxfoundation.org> writes:
>
>> On Tue, Nov 23, 2021 at 07:29:43PM +0200, Thomas Backlund wrote:
>>> Den 2021-11-22 kl. 14:31, skrev gregkh@linuxfoundation.org:
>>>> The patch below does not apply to the 5.15-stable tree.
>>>> If someone wants it applied there, or to any other stable or longterm
>>>> tree, then please email the backport, including the original git commit
>>>> id to <stable@vger.kernel.org>.
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>
>>> It will apply if you add this one first:
>>>
>>> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>>> Subject: [PATCH] signal: Implement force_fatal_sig
>>>
>>>
>>>
>>>
>>> and if the other patch for signal that has similar description should land
>>> in 5.15:
>>>
>>> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>>> doubt
>>>
>>>
>>>
>>> then the list is looks something like:
>>>
>>>
>>> From 941edc5bf174b67f94db19817cbeab0a93e0c32a Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:44:00 -0500
>>> Subject: [PATCH] exit/syscall_user_dispatch: Send ordinary signals on
>>> failure
>>>
>>> From 83a1f27ad773b1d8f0460d3a676114c7651918cc Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:53 -0500
>>> Subject: [PATCH] signal/powerpc: On swapcontext failure force SIGSEGV
>>>
>>> From 9bc508cf0791c8e5a37696de1a046d746fcbd9d8 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:57 -0500
>>> Subject: [PATCH] signal/s390: Use force_sigsegv in default_trap_handler
>>>
>>> From c317d306d55079525c9610267fdaf3a8a6d2f08b Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:44:01 -0500
>>> Subject: [PATCH] signal/sparc32: Exit with a fatal signal when
>>> try_to_clear_window_buffer fails
>>>
>>> From 086ec444f86660e103de8945d0dcae9b67132ac9 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:44:02 -0500
>>> Subject: [PATCH] signal/sparc32: In setup_rt_frame and setup_fram use
>>> force_fatal_sig
>>>
>>> From 1fbd60df8a852d9c55de8cd3621899cf4c72a5b7 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:56 -0500
>>> Subject: [PATCH] signal/vm86_32: Properly send SIGSEGV when the vm86 state
>>> cannot be saved.
>>>
>>> From 695dd0d634df8903e5ead8aa08d326f63b23368a Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:44:03 -0500
>>> Subject: [PATCH] signal/x86: In emulate_vsyscall force a signal instead of
>>> calling do_exit
>>>
>>> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>>> Subject: [PATCH] signal: Implement force_fatal_sig
>>>
>>> From e21294a7aaae32c5d7154b187113a04db5852e37 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Mon, 25 Oct 2021 10:50:57 -0500
>>> Subject: [PATCH] signal: Replace force_sigsegv(SIGSEGV) with
>>> force_fatal_sig(SIGSEGV)
>>>
>>> From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Thu, 18 Nov 2021 11:11:13 -0600
>>> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>>>
>>> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>>> doubt
>>>
>>>
>>>
>>> Applying them in listed order on top of 5.14.4 and builds/runs on i586,
>>> x86_64, armv7hl, aarch64
>> That series list is crazy, let me go try it and see what blows up! :)
> Maybe I am wrong but I think "Don't always set SA_IMMUTABLE for forced
> signals" will apply if you drop the hunk modifying force_fatal_sig.
> Then you don't need to backport all of the cleanups just the fix.
>
> I will take a quick look and verify that.
that's why i wrote: "if the other patch for signal that has similar
description should land"
(meaning "signal: Replace force_fatal_sig with force_exit_sig when in
doubt")
as thats the one needing the whole patch series...
since going by patch descriptions for:
"signal: Don't always set SA_IMMUTABLE for forced signals"
"signal: Replace force_fatal_sig with force_exit_sig when in doubt"
both has the info:
"Unfortunately this broke debuggers[1][2] which reasonably expect
to be able to trap synchronous SIGTRAP and SIGSEGV even when
the target process is not configured to handle those signals."
and the second even has:
"This avoids userspace regressions as older kernels exited with do_exit
which debuggers also can not intercept."
or is the patch description on the second patch somewhat misleading ?
--
Thomas
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-23 20:00 ` Thomas Backlund
@ 2021-11-23 21:41 ` Eric W. Biederman
2021-11-23 21:56 ` Thomas Backlund
0 siblings, 1 reply; 13+ messages in thread
From: Eric W. Biederman @ 2021-11-23 21:41 UTC (permalink / raw)
To: Thomas Backlund
Cc: Greg KH, keescook, khuey, me, oliver.sang, torvalds, stable
Thomas Backlund <tmb@iki.fi> writes:
> Den 2021-11-23 kl. 21:24, skrev ebiederm@xmission.com:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>>
>>> On Tue, Nov 23, 2021 at 07:29:43PM +0200, Thomas Backlund wrote:
>>>> Den 2021-11-22 kl. 14:31, skrev gregkh@linuxfoundation.org:
>>>>> The patch below does not apply to the 5.15-stable tree.
>>>>> If someone wants it applied there, or to any other stable or longterm
>>>>> tree, then please email the backport, including the original git commit
>>>>> id to <stable@vger.kernel.org>.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>
>>>> It will apply if you add this one first:
>>>>
>>>> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>>>> Subject: [PATCH] signal: Implement force_fatal_sig
>>>>
>>>>
>>>>
>>>>
>>>> and if the other patch for signal that has similar description should land
>>>> in 5.15:
>>>>
>>>> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>>>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>>>> doubt
>>>>
>>>>
>>>>
>>>> then the list is looks something like:
>>>>
>>>>
>>>> From 941edc5bf174b67f94db19817cbeab0a93e0c32a Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:44:00 -0500
>>>> Subject: [PATCH] exit/syscall_user_dispatch: Send ordinary signals on
>>>> failure
>>>>
>>>> From 83a1f27ad773b1d8f0460d3a676114c7651918cc Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:53 -0500
>>>> Subject: [PATCH] signal/powerpc: On swapcontext failure force SIGSEGV
>>>>
>>>> From 9bc508cf0791c8e5a37696de1a046d746fcbd9d8 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:57 -0500
>>>> Subject: [PATCH] signal/s390: Use force_sigsegv in default_trap_handler
>>>>
>>>> From c317d306d55079525c9610267fdaf3a8a6d2f08b Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:44:01 -0500
>>>> Subject: [PATCH] signal/sparc32: Exit with a fatal signal when
>>>> try_to_clear_window_buffer fails
>>>>
>>>> From 086ec444f86660e103de8945d0dcae9b67132ac9 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:44:02 -0500
>>>> Subject: [PATCH] signal/sparc32: In setup_rt_frame and setup_fram use
>>>> force_fatal_sig
>>>>
>>>> From 1fbd60df8a852d9c55de8cd3621899cf4c72a5b7 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:56 -0500
>>>> Subject: [PATCH] signal/vm86_32: Properly send SIGSEGV when the vm86 state
>>>> cannot be saved.
>>>>
>>>> From 695dd0d634df8903e5ead8aa08d326f63b23368a Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:44:03 -0500
>>>> Subject: [PATCH] signal/x86: In emulate_vsyscall force a signal instead of
>>>> calling do_exit
>>>>
>>>> From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>>>> Subject: [PATCH] signal: Implement force_fatal_sig
>>>>
>>>> From e21294a7aaae32c5d7154b187113a04db5852e37 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Mon, 25 Oct 2021 10:50:57 -0500
>>>> Subject: [PATCH] signal: Replace force_sigsegv(SIGSEGV) with
>>>> force_fatal_sig(SIGSEGV)
>>>>
>>>> From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Thu, 18 Nov 2021 11:11:13 -0600
>>>> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>>>>
>>>> From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>>>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>>>> doubt
>>>>
>>>>
>>>>
>>>> Applying them in listed order on top of 5.14.4 and builds/runs on i586,
>>>> x86_64, armv7hl, aarch64
>>> That series list is crazy, let me go try it and see what blows up! :)
>> Maybe I am wrong but I think "Don't always set SA_IMMUTABLE for forced
>> signals" will apply if you drop the hunk modifying force_fatal_sig.
>> Then you don't need to backport all of the cleanups just the fix.
>>
>> I will take a quick look and verify that.
>
>
> that's why i wrote: "if the other patch for signal that has similar
> description should land"
Apologies for not responding to that bit, I was reading quickly
and I missed that bit.
The second patch does not need to land in 5.15.
> (meaning "signal: Replace force_fatal_sig with force_exit_sig when in
> doubt")
>
> as thats the one needing the whole patch series...
>
>
> since going by patch descriptions for:
>
> "signal: Don't always set SA_IMMUTABLE for forced signals"
>
> "signal: Replace force_fatal_sig with force_exit_sig when in doubt"
>
>
> both has the info:
>
> "Unfortunately this broke debuggers[1][2] which reasonably expect
> to be able to trap synchronous SIGTRAP and SIGSEGV even when
> the target process is not configured to handle those signals."
>
> and the second even has:
> "This avoids userspace regressions as older kernels exited with do_exit
> which debuggers also can not intercept."
>
>
> or is the patch description on the second patch somewhat misleading ?
It is the same problem. But it only applies to code that was merged
post 5.15.
For 5.15 on force_sig_seccomp is really affected.
For 5.16 there were many calls to do_exit that I turned into signals.
Some of the properly should be oridinary signals and some of them
for correctness purposes can't allow debuggers or userspace to intercept
them.
The second patch went through and modified everything that was
non-interceptible before 5.16 to be non-interceptible in 5.16. Where
that is not necessary we can relax things later.
But for 5.15 only the one patch needs to be applied.
Eric
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-23 21:41 ` Eric W. Biederman
@ 2021-11-23 21:56 ` Thomas Backlund
0 siblings, 0 replies; 13+ messages in thread
From: Thomas Backlund @ 2021-11-23 21:56 UTC (permalink / raw)
To: ebiederm, Thomas Backlund
Cc: Greg KH, keescook, khuey, me, oliver.sang, torvalds, stable
Den 2021-11-23 kl. 23:41, skrev ebiederm@xmission.com:
> Thomas Backlund <tmb@iki.fi> writes:
>
>> Den 2021-11-23 kl. 21:24, skrev ebiederm@xmission.com:
>>> Maybe I am wrong but I think "Don't always set SA_IMMUTABLE for forced
>>> signals" will apply if you drop the hunk modifying force_fatal_sig.
>>> Then you don't need to backport all of the cleanups just the fix.
>>>
>>> I will take a quick look and verify that.
>>
>> that's why i wrote: "if the other patch for signal that has similar
>> description should land"
> Apologies for not responding to that bit, I was reading quickly
> and I missed that bit.
No worries :)
> The second patch does not need to land in 5.15.
>> (meaning "signal: Replace force_fatal_sig with force_exit_sig when in
>> doubt")
>>
>> as thats the one needing the whole patch series...
>>
>>
>> since going by patch descriptions for:
>>
>> "signal: Don't always set SA_IMMUTABLE for forced signals"
>>
>> "signal: Replace force_fatal_sig with force_exit_sig when in doubt"
>>
>>
>> both has the info:
>>
>> "Unfortunately this broke debuggers[1][2] which reasonably expect
>> to be able to trap synchronous SIGTRAP and SIGSEGV even when
>> the target process is not configured to handle those signals."
>>
>> and the second even has:
>> "This avoids userspace regressions as older kernels exited with do_exit
>> which debuggers also can not intercept."
>>
>>
>> or is the patch description on the second patch somewhat misleading ?
> It is the same problem. But it only applies to code that was merged
> post 5.15.
>
> For 5.15 on force_sig_seccomp is really affected.
>
> For 5.16 there were many calls to do_exit that I turned into signals.
> Some of the properly should be oridinary signals and some of them
> for correctness purposes can't allow debuggers or userspace to intercept
> them.
>
> The second patch went through and modified everything that was
> non-interceptible before 5.16 to be non-interceptible in 5.16. Where
> that is not necessary we can relax things later.
>
> But for 5.15 only the one patch needs to be applied.
>
> Eric
Thanks for the explanation.
--
Thomas
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-22 12:31 FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree gregkh
2021-11-23 15:08 ` Kyle Huey
2021-11-23 17:29 ` Thomas Backlund
@ 2021-11-24 1:33 ` Kyle Huey
2021-11-24 5:15 ` Eric W. Biederman
2 siblings, 1 reply; 13+ messages in thread
From: Kyle Huey @ 2021-11-24 1:33 UTC (permalink / raw)
To: gregkh, Robert O'Callahan
Cc: Eric W. Biederman, Kees Cook, Kyle Huey, Oliver Sang,
Linus Torvalds, stable
On Mon, Nov 22, 2021 at 4:31 AM <gregkh@linuxfoundation.org> wrote:
>
>
> The patch below does not apply to the 5.15-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> thanks,
>
> greg k-h
>
> ------------------ original commit in Linus's tree ------------------
>
> From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Thu, 18 Nov 2021 11:11:13 -0600
> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>
> Recently to prevent issues with SECCOMP_RET_KILL and similar signals
> being changed before they are delivered SA_IMMUTABLE was added.
>
> Unfortunately this broke debuggers[1][2] which reasonably expect to be
> able to trap synchronous SIGTRAP and SIGSEGV even when the target
> process is not configured to handle those signals.
>
> Update force_sig_to_task to support both the case when we can allow
> the debugger to intercept and possibly ignore the signal and the case
> when it is not safe to let userspace know about the signal until the
> process has exited.
>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Reported-by: Kyle Huey <me@kylehuey.com>
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Cc: stable@vger.kernel.org
> [1] https://lkml.kernel.org/r/CAP045AoMY4xf8aC_4QU_-j7obuEPYgTcnQQP3Yxk=2X90jtpjw@mail.gmail.com
> [2] https://lkml.kernel.org/r/20211117150258.GB5403@xsang-OptiPlex-9020
> Fixes: 00b06da29cf9 ("signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed")
> Link: https://lkml.kernel.org/r/877dd5qfw5.fsf_-_@email.froward.int.ebiederm.org
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Tested-by: Kees Cook <keescook@chromium.org>
> Tested-by: Kyle Huey <khuey@kylehuey.com>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 7c4b7ae714d4..7815e1bbeddc 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1298,6 +1298,12 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p
> return ret;
> }
>
> +enum sig_handler {
> + HANDLER_CURRENT, /* If reachable use the current handler */
> + HANDLER_SIG_DFL, /* Always use SIG_DFL handler semantics */
> + HANDLER_EXIT, /* Only visible as the process exit code */
> +};
> +
> /*
> * Force a signal that the process can't ignore: if necessary
> * we unblock the signal and change any SIG_IGN to SIG_DFL.
> @@ -1310,7 +1316,8 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p
> * that is why we also clear SIGNAL_UNKILLABLE.
> */
> static int
> -force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool sigdfl)
> +force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t,
> + enum sig_handler handler)
> {
> unsigned long int flags;
> int ret, blocked, ignored;
> @@ -1321,9 +1328,10 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool
> action = &t->sighand->action[sig-1];
> ignored = action->sa.sa_handler == SIG_IGN;
> blocked = sigismember(&t->blocked, sig);
> - if (blocked || ignored || sigdfl) {
> + if (blocked || ignored || (handler != HANDLER_CURRENT)) {
> action->sa.sa_handler = SIG_DFL;
> - action->sa.sa_flags |= SA_IMMUTABLE;
> + if (handler == HANDLER_EXIT)
> + action->sa.sa_flags |= SA_IMMUTABLE;
> if (blocked) {
> sigdelset(&t->blocked, sig);
> recalc_sigpending_and_wake(t);
> @@ -1343,7 +1351,7 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool
>
> int force_sig_info(struct kernel_siginfo *info)
> {
> - return force_sig_info_to_task(info, current, false);
> + return force_sig_info_to_task(info, current, HANDLER_CURRENT);
> }
>
> /*
> @@ -1660,7 +1668,7 @@ void force_fatal_sig(int sig)
> info.si_code = SI_KERNEL;
> info.si_pid = 0;
> info.si_uid = 0;
> - force_sig_info_to_task(&info, current, true);
> + force_sig_info_to_task(&info, current, HANDLER_SIG_DFL);
> }
>
> /*
> @@ -1693,7 +1701,7 @@ int force_sig_fault_to_task(int sig, int code, void __user *addr
> info.si_flags = flags;
> info.si_isr = isr;
> #endif
> - return force_sig_info_to_task(&info, t, false);
> + return force_sig_info_to_task(&info, t, HANDLER_CURRENT);
> }
>
> int force_sig_fault(int sig, int code, void __user *addr
> @@ -1813,7 +1821,8 @@ int force_sig_seccomp(int syscall, int reason, bool force_coredump)
> info.si_errno = reason;
> info.si_arch = syscall_get_arch(current);
> info.si_syscall = syscall;
> - return force_sig_info_to_task(&info, current, force_coredump);
> + return force_sig_info_to_task(&info, current,
> + force_coredump ? HANDLER_EXIT : HANDLER_CURRENT);
> }
>
> /* For the crazy architectures that include trap information in
>
Since this is taken care of now, AFAICT, I do have one additional
question. I reported the regression to LKML a day or so before 5.15.3
was cut. What should I have noticed to see that the regressing
changeset was going to 5.15 and where should I have said "hey please
don't ship this on 5.15 yet"?
I'd like to know what to do next time :)
- Kyle
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-24 1:33 ` Kyle Huey
@ 2021-11-24 5:15 ` Eric W. Biederman
2021-11-29 6:23 ` Kyle Huey
0 siblings, 1 reply; 13+ messages in thread
From: Eric W. Biederman @ 2021-11-24 5:15 UTC (permalink / raw)
To: Kyle Huey
Cc: gregkh, Robert O'Callahan, Kees Cook, Kyle Huey, Oliver Sang,
Linus Torvalds, stable
Kyle Huey <me@kylehuey.com> writes:
> Since this is taken care of now, AFAICT, I do have one additional
> question. I reported the regression to LKML a day or so before 5.15.3
> was cut. What should I have noticed to see that the regressing
> changeset was going to 5.15 and where should I have said "hey please
> don't ship this on 5.15 yet"?
>
> I'd like to know what to do next time :)
>
When patches are added to the stable tree they are posted
for review.
I was Cc'd on a couple of them because of this discussion. The list
appear to be "<stable-commits@vger.kernel.org>". Feedback is requested
to go to "<stable@vger.kernel.org>". So I believe this conversation is
enough to remove the unnecessary patches before they make it to a stable
release.
The boiler plate looks like:
> Cc: <stable-commits@vger.kernel.org>
> Date: Tue, 23 Nov 2021 19:11:53 +0100 (10 hours, 58 minutes, 56 seconds ago)
>
>
> This is a note to let you know that I've just added the patch titled
>
> exit/syscall_user_dispatch: Send ordinary signals on failure
>
> to the 5.15-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> exit-syscall_user_dispatch-send-ordinary-signals-on-failure.patch
> and it can be found in the queue-5.15 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
I hope that helps.
Eric
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-24 5:15 ` Eric W. Biederman
@ 2021-11-29 6:23 ` Kyle Huey
2021-11-29 6:43 ` Greg KH
0 siblings, 1 reply; 13+ messages in thread
From: Kyle Huey @ 2021-11-29 6:23 UTC (permalink / raw)
To: Eric W. Biederman
Cc: gregkh, Robert O'Callahan, Kees Cook, Kyle Huey, Oliver Sang,
Linus Torvalds, stable
On Tue, Nov 23, 2021 at 9:15 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Kyle Huey <me@kylehuey.com> writes:
>
>
> > Since this is taken care of now, AFAICT, I do have one additional
> > question. I reported the regression to LKML a day or so before 5.15.3
> > was cut. What should I have noticed to see that the regressing
> > changeset was going to 5.15 and where should I have said "hey please
> > don't ship this on 5.15 yet"?
> >
> > I'd like to know what to do next time :)
> >
> When patches are added to the stable tree they are posted
> for review.
>
> I was Cc'd on a couple of them because of this discussion. The list
> appear to be "<stable-commits@vger.kernel.org>". Feedback is requested
> to go to "<stable@vger.kernel.org>". So I believe this conversation is
> enough to remove the unnecessary patches before they make it to a stable
> release.
>
> The boiler plate looks like:
> > Cc: <stable-commits@vger.kernel.org>
> > Date: Tue, 23 Nov 2021 19:11:53 +0100 (10 hours, 58 minutes, 56 seconds ago)
> >
> >
> > This is a note to let you know that I've just added the patch titled
> >
> > exit/syscall_user_dispatch: Send ordinary signals on failure
> >
> > to the 5.15-stable tree which can be found at:
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> >
> > The filename of the patch is:
> > exit-syscall_user_dispatch-send-ordinary-signals-on-failure.patch
> > and it can be found in the queue-5.15 subdirectory.
> >
> > If you, or anyone else, feels it should not be added to the stable tree,
> > please let <stable@vger.kernel.org> know about it.
>
>
> I hope that helps.
>
> Eric
So if I understand this correctly the best (or maybe even only) way to
stop a regressing changeset from making it into a stable release is to
separately search/watch the stable mailing list for the changeset in
question?
- Kyle
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree
2021-11-29 6:23 ` Kyle Huey
@ 2021-11-29 6:43 ` Greg KH
0 siblings, 0 replies; 13+ messages in thread
From: Greg KH @ 2021-11-29 6:43 UTC (permalink / raw)
To: Kyle Huey
Cc: Eric W. Biederman, Robert O'Callahan, Kees Cook, Kyle Huey,
Oliver Sang, Linus Torvalds, stable
On Sun, Nov 28, 2021 at 10:23:38PM -0800, Kyle Huey wrote:
> On Tue, Nov 23, 2021 at 9:15 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> >
> > Kyle Huey <me@kylehuey.com> writes:
> >
> >
> > > Since this is taken care of now, AFAICT, I do have one additional
> > > question. I reported the regression to LKML a day or so before 5.15.3
> > > was cut. What should I have noticed to see that the regressing
> > > changeset was going to 5.15 and where should I have said "hey please
> > > don't ship this on 5.15 yet"?
> > >
> > > I'd like to know what to do next time :)
> > >
> > When patches are added to the stable tree they are posted
> > for review.
> >
> > I was Cc'd on a couple of them because of this discussion. The list
> > appear to be "<stable-commits@vger.kernel.org>". Feedback is requested
> > to go to "<stable@vger.kernel.org>". So I believe this conversation is
> > enough to remove the unnecessary patches before they make it to a stable
> > release.
> >
> > The boiler plate looks like:
> > > Cc: <stable-commits@vger.kernel.org>
> > > Date: Tue, 23 Nov 2021 19:11:53 +0100 (10 hours, 58 minutes, 56 seconds ago)
> > >
> > >
> > > This is a note to let you know that I've just added the patch titled
> > >
> > > exit/syscall_user_dispatch: Send ordinary signals on failure
> > >
> > > to the 5.15-stable tree which can be found at:
> > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > >
> > > The filename of the patch is:
> > > exit-syscall_user_dispatch-send-ordinary-signals-on-failure.patch
> > > and it can be found in the queue-5.15 subdirectory.
> > >
> > > If you, or anyone else, feels it should not be added to the stable tree,
> > > please let <stable@vger.kernel.org> know about it.
> >
> >
> > I hope that helps.
> >
> > Eric
>
> So if I understand this correctly the best (or maybe even only) way to
> stop a regressing changeset from making it into a stable release is to
> separately search/watch the stable mailing list for the changeset in
> question?
That is the best way, yes.
But note that I also cc: lkml with all stable patches for when they are
in a -rc release to give developers time to object if needed as well, so
you can search there too.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread