lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aBnvJYXqsfn0YG19@redhat.com>
Date: Tue, 6 May 2025 13:14:45 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Sasha Levin <sashal@...nel.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Christian Brauner <brauner@...nel.org>, akpm@...ux-foundation.org,
	mhocko@...e.com, mjguzik@...il.com, pasha.tatashin@...een.com,
	alexjlzheng@...cent.com
Subject: Re: [PATCH AUTOSEL 6.14 046/642] exit: fix the usage of
 delay_group_leader->exit_code in do_notify_parent() and pidfs_exit()

I'm on PTO until May 15, can't read the code.

Does 6.14 have pidfs_exit() ? If no, then I don't think this patch should be
backported.

Yes, do_notify_parent() can use the "wrong" exit_code too, but this is minor
and we need more changes to make it actually correct.

Oleg.

On 05/05, Sasha Levin wrote:
>
> From: Oleg Nesterov <oleg@...hat.com>
> 
> [ Upstream commit 9133607de37a4887c6f89ed937176a0a0c1ebb17 ]
> 
> Consider a process with a group leader L and a sub-thread T.
> L does sys_exit(1), then T does sys_exit_group(2).
> 
> In this case wait_task_zombie(L) will notice SIGNAL_GROUP_EXIT and use
> L->signal->group_exit_code, this is correct.
> 
> But, before that, do_notify_parent(L) called by release_task(T) will use
> L->exit_code != L->signal->group_exit_code, and this is not consistent.
> We don't really care, I think that nobody relies on the info which comes
> with SIGCHLD, if nothing else SIGCHLD < SIGRTMIN can be queued only once.
> 
> But pidfs_exit() is more problematic, I think pidfs_exit_info->exit_code
> should report ->group_exit_code in this case, just like wait_task_zombie().
> 
> TODO: with this change we can hopefully cleanup (or may be even kill) the
> similar SIGNAL_GROUP_EXIT checks, at least in wait_task_zombie().
> 
> Signed-off-by: Oleg Nesterov <oleg@...hat.com>
> Link: https://lore.kernel.org/r/20250324171941.GA13114@redhat.com
> Signed-off-by: Christian Brauner <brauner@...nel.org>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---
>  kernel/exit.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 3485e5fc499e4..6bb59b16e33e1 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -265,6 +265,9 @@ void release_task(struct task_struct *p)
>  	leader = p->group_leader;
>  	if (leader != p && thread_group_empty(leader)
>  			&& leader->exit_state == EXIT_ZOMBIE) {
> +		/* for pidfs_exit() and do_notify_parent() */
> +		if (leader->signal->flags & SIGNAL_GROUP_EXIT)
> +			leader->exit_code = leader->signal->group_exit_code;
>  		/*
>  		 * If we were the last child thread and the leader has
>  		 * exited already, and the leader's parent ignores SIGCHLD,
> -- 
> 2.39.5
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ