linux-kernel - Re: [PATCH v2 3/4] seccomp: add a way to get a listener fd from ptrace

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: <20180517155733.GB3831@cisco>
Date:   Thu, 17 May 2018 09:57:33 -0600
From:   Tycho Andersen <tycho@...ho.ws>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        containers@...ts.linux-foundation.org,
        Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...capital.net>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        "Serge E . Hallyn" <serge@...lyn.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Tyler Hicks <tyhicks@...onical.com>,
        Akihiro Suda <suda.akihiro@....ntt.co.jp>,
        "Tobin C . Harding" <me@...in.cc>
Subject: Re: [PATCH v2 3/4] seccomp: add a way to get a listener fd from
 ptrace

On Thu, May 17, 2018 at 05:41:39PM +0200, Oleg Nesterov wrote:
> again, I don't understand this code yet, but
> 
> On 05/17, Tycho Andersen wrote:
> >
> > +long seccomp_get_listener(struct task_struct *task,
> > +			  unsigned long filter_off)
> > +{
> > +	struct seccomp_filter *filter;
> > +	struct file *listener;
> > +	int fd;
> > +
> > +	filter = get_nth_filter(task, filter_off);
> > +	if (IS_ERR(filter))
> > +		return PTR_ERR(filter);
> > +
> > +	fd = get_unused_fd_flags(O_RDWR);
> > +	if (fd < 0) {
> > +		__put_seccomp_filter(filter);
> > +		return fd;
> > +	}
> > +
> > +	listener = init_listener(task, task->seccomp.filter);
> > +	if (IS_ERR(listener)) {
> > +		put_unused_fd(fd);
> > +		return PTR_ERR(listener);
> 
> __put_seccomp_filter() ?

Yes, I think you're right here.

> and since init_listener() does __get_seccomp_filter() on sucess, it is needed
> uncondtitionally?

I think there does need to be a __get_seccomp_filter() on success in
init_listener(), because it's paired with the __put_seccomp_filter in
seccomp_notify_release. The listener fd has a reference to the filter,
and that shouldn't go away until after the fd is freed.

Tycho