linux-kernel - Re: + exitc-call-proc_exit_connector-after-exit

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-next>] [day] [month] [year] [list]

Date:	Tue, 25 Feb 2014 16:10:43 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	akpm@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org, matt.helsley@...il.com,
	davem@...emloft.net, guillaume@...infr.org
Subject: Re: + exitc-call-proc_exit_connector-after-exit_state-is-set.patch
	added to -mm tree

> The process events connector delivers a notification when a process exits.
>  This is really convenient for a process that spawns and wants to monitor
> its children through an epoll-able() interface.
>
> Unfortunately, there is a small window between when the event is delivered
> and the child become wait()-able.
>
> This is creates a race if the parent wants to make sure that it knows
> about the exit, e.g
>
> pid_t pid = fork();
> if (pid > 0) {
> 	register_interest_for_pid(pid);
> 	if (waitpid(pid, NULL, WNOHANG) > 0)
> 	{
> 	  /* We might have raced with exit() */
> 	}

Just in case... Even with this patch the code above is still "racy" if the
child is multi-threaded. Plus it should obviously filter-out subthreads.
And afaics there is no way to make it reliable, even if you change the
code above so that waitpid() is called only after the last thread exits
WNOHANG still can fail.

Not that I am not arguing with this change. Although I hope that someone
can confirm that netlink_broadcast() is safe even if release_task(current)
was already called, so that the caller has no pids, sighand, is not visible
via /proc/, etc.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/