linux-kernel - Re: [PATCH v2] fs: Allow opening only regular files during execve().

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: <201902120201.x1C21wt2019144@www262.sakura.ne.jp>
Date:   Tue, 12 Feb 2019 11:01:58 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>
Cc:     Eric Biggers <ebiggers3@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        syzbot 
        <bot+e93a80c1bb7c5c56e522461c149f8bf55eab1b2b@...kaller.appspotmail.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH v2] fs: Allow opening only regular files during execve().

Andrew Morton wrote:
> > --- a/fs/open.c
> > +++ b/fs/open.c
> > @@ -733,6 +733,12 @@ static int do_dentry_open(struct file *f,
> >  		return 0;
> >  	}
> >  
> > +	/* Any file opened for execve()/uselib() has to be a regular file. */
> > +	if (unlikely(f->f_flags & FMODE_EXEC && !S_ISREG(inode->i_mode))) {
> > +		error = -EACCES;
> > +		goto cleanup_file;
> > +	}
> > +
> >  	if (f->f_mode & FMODE_WRITE && !special_file(inode->i_mode)) {
> >  		error = get_write_access(inode);
> >  		if (unlikely(error))
> 
> This change sounds legitimate for various other reasons, but it's a
> concern that this locking error occurred in the first place.  There's a
> problem somewhere (probably the pipe code) which may bite us in other
> situations, even with this workaround in place.
> 
> 

This error seems to be introduced in 2.6.39-rc1 by commit a9712bc12c40c172
("deal with races in /proc/*/{syscall,stack,personality}"). Thus, I don't
think that this patch will bite us in other situations.
Al, how do you want to handle this?