Re: [PATCH] signal: avoid shared siginfo namespace rewrites

From: Bradley Morgan

Date: Mon Jun 22 2026 - 16:06:34 EST


On June 22, 2026 6:46:37 PM GMT+01:00, Oleg Nesterov <oleg@xxxxxxxxxx>
wrote:
>On 06/22, Bradley Morgan wrote:
>>
>> send_signal_locked() rewrites sender ids for the target namespace.
>> Group sends reuse the same siginfo, so one recipient can affect the
>> next.
>
>Hmm... I'll re-read this change tomorrow after sleep, but I am almost sure
>you are you are right anyway...

Sure! Feel free to take ur time!

>I am wondering if we can conditionalize the "swap(rewritten, info)" logic
>with your patch, most probably this makes no sense...
>
>May I suggest another change on top of your fix? Make the "kernel_siginfo
>*info"
>arg of send_signal_locked() "const". To make it more clear. Yes, the
>signature
>of has_si_pid_and_uid() should be changed too. Up to you.

I'll do it. I don't mind.

>Thanks,
>
>Oleg.
>
>> Copy the siginfo before changing it.
>>
>> Fixes: 7a0cf094944e ("signal: Correct namespace fixups of si_pid and
>si_uid")
>> Cc: stable@xxxxxxxxxxxxxxx
>> Signed-off-by: Bradley Morgan <include@xxxxxxxxx>
>> ---
>> kernel/signal.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/kernel/signal.c b/kernel/signal.c
>> index b9fc7be1a169..d72d9be3a992 100644
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -1181,6 +1181,7 @@ static inline bool has_si_pid_and_uid(struct
>kernel_siginfo *info)
>> int send_signal_locked(int sig, struct kernel_siginfo *info,
>> struct task_struct *t, enum pid_type type)
>> {
>> + struct kernel_siginfo rewritten;
>> /* Should SIGKILL or SIGSTOP be received by a pid namespace init? */
>> bool force = false;
>>
>> @@ -1194,6 +1195,9 @@ int send_signal_locked(int sig, struct
>kernel_siginfo *info,
>> /* SIGKILL and SIGSTOP is special or has ids */
>> struct user_namespace *t_user_ns;
>>
>> + rewritten = *info;
>> + info = &rewritten;
>> +
>> rcu_read_lock();
>> t_user_ns = task_cred_xxx(t, user_ns);
>> if (current_user_ns() != t_user_ns) {
>> --
>> 2.53.0
>>
>
>

Thanks!