Re: [PATCH] fork: fix pid refcount leaks when destroying file

[Christian Brauner <christian.brauner@ubuntu.com>]

On Sun, Jul 26, 2020 at 12:49:59PM +0800, Xin Xiong wrote:
> When clone_flags & CLONE_PIDFD is true,the function creates a new file
> object called pidfile,and invokes get_pid(),which increases the refcnt
> of pid for pidfile to hold.
> 
> The reference counting issues take place in the error handling paths.
> When error occurs after the construction of pidfile, the function only
> invokes fput() to destroy pidfile, in which the increased refcount
> won't be decreased, resulting in a refcount leak.
> 
> Fix this issue by adding put_pid() in the error handling path
> bad_fork_put_pidfd.
> 
> Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
> Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
> ---
>  kernel/fork.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 142b23645d82..7cbfb2c4fce3 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2319,6 +2319,7 @@ static __latent_entropy struct task_struct *copy_process(
>  bad_fork_put_pidfd:
>  	if (clone_flags & CLONE_PIDFD) {
>  		fput(pidfile);
> +		put_pid(pid);
>  		put_unused_fd(pidfd);

Thanks for the patch but this is actually wrong. If you look further up
where pidfile is allocated you'll see the comment

		get_pid(pid);	/* held by pidfile now */

which I added to inidicate that the additional reference to struct pid
has now been transferred to the pidfile and is released when the file is
released. So the last fput(pidfile) will cause the vfs to call the
files' ->release() method which in this case is

static int pidfd_release(struct inode *inode, struct file *file)
{
	struct pid *pid = file->private_data;

	file->private_data = NULL;
	put_pid(pid);
	return 0;
}

Since fput(pidfile) in the bad_fork_put_pidfd error path is the only
reference to the pidfile the struct pid reference count will be
decremented.

Your additional put_pid() will cause a UAF which you should've seen
during testing if you injected an error by setting CLONE_PIDFD e.g. by
providing NULL as the args->pidfd argument to clone3() or NULL to the
parent_tidptr argument of clone() or by placing the parent into a cgroup
whos current pid_max limit doesn't allow it to fork.

Thanks!
Christian