From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <kees@kernel.org>,
Kusaram Devineni <kusaram@devineni.in>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>, Will Drewry <wad@chromium.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/3] signal: change force_sig_info_to_task() to call __send_signal_locked()
Date: Fri, 19 Jun 2026 15:27:10 +0200 [thread overview]
Message-ID: <ajVDrvY01xRW2x72@redhat.com> (raw)
force_sig_info_to_task() calls send_signal_locked() which does two
things on top of __send_signal_locked():
1. The namespace translation of si_pid/si_uid. However, forced signals
carry fault info (si_addr, si_call_addr, si_syscall), not pid/uid.
The force_sig*() API should never be used to send signals with
meaningful si_pid/si_uid, the forced signals are always "from kernel".
There are few users of force_sig(SIGKILL), and in this case
send_signal_locked() -> has_si_pid_and_uid() returns true.
However, __send_signal_locked() simply ignores kernel_siginfo if
sig == SIGKILL.
(and in fact force_sig(SIGKILL) makes little sense, they should
use send_sig(SIGKILL, p, 1) instead)
2. The "force" computation. However, for the forced signals, the
unconditional force == true works just fine.
If the target is ptraced, the "force" arg has no effect unless
sig == SIGKILL.
Otherwise, this check in sig_task_ignored()
if (unlikely(t->signal->flags & SIGNAL_UNKILLABLE) &&
handler == SIG_DFL && !(force && sig_kernel_only(sig)))
return true;
has no effect, force_sig_info_to_task() clears SIGNAL_UNKILLABLE
if handler == SIG_DFL.
The only behavioral difference is another check in sig_task_ignored:
if (unlikely((t->flags & PF_KTHREAD) &&
(handler == SIG_KTHREAD_KERNEL) && !force))
So with this patch a kthread that called allow_kernel_signal()
for a fault signal would now receive the forced signal instead
of silently ignoring it.
And this is arguably more correct, even if I don't think that
the force_sig*() API should be used in this case.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
kernel/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 9c2b32c4d755..68af503ed43c 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1315,7 +1315,7 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t,
if (action->sa.sa_handler == SIG_DFL &&
(!t->ptrace || (handler == HANDLER_EXIT)))
t->signal->flags &= ~SIGNAL_UNKILLABLE;
- ret = send_signal_locked(sig, info, t, PIDTYPE_PID);
+ ret = __send_signal_locked(sig, info, t, PIDTYPE_PID, true);
/* This can happen if the signal was already pending and blocked */
if (!task_sigpending(t))
signal_wake_up(t, 0);
--
2.52.0
next reply other threads:[~2026-06-19 13:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 13:27 Oleg Nesterov [this message]
2026-06-19 13:27 ` [PATCH v2 2/3] signal: turn the "bool force" arg of __send_signal_locked() into "int flags" Oleg Nesterov
2026-06-19 13:28 ` [PATCH v2 3/3] signal: fix evasion of SA_IMMUTABLE signals Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ajVDrvY01xRW2x72@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=kees@kernel.org \
--cc=kusaram@devineni.in \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.