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

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

Date:   Sun, 26 Jul 2020 11:06:05 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Xin Xiong <xiongx18@...an.edu.cn>
Cc:     Christian Brauner <christian@...uner.io>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Christian Kellner <christian@...lner.me>,
        Adrian Reber <areber@...hat.com>,
        Aleksa Sarai <cyphar@...har.com>, linux-kernel@...r.kernel.org,
        Xiyu Yang <xiyuyang19@...an.edu.cn>,
        Xin Tan <tanxin.ctf@...il.com>, yuanxzhang@...an.edu.cn
Subject: Re: [PATCH] fork: fix pid refcount leaks when destroying file

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@...an.edu.cn>
> Signed-off-by: Xin Tan <tanxin.ctf@...il.com>
> Signed-off-by: Xin Xiong <xiongx18@...an.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