linux-kernel - Re: [PATCH] filelock: move file locking definitions to separate header 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]

Message-ID: <6a093484bb977355db40c70ffa51386f3d4ed57b.camel@kernel.org>
Date:   Mon, 28 Nov 2022 05:53:54 -0500
From:   Jeff Layton <jlayton@...nel.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Eric Van Hensbergen <ericvh@...il.com>,
        Latchesar Ionkov <lucho@...kov.net>,
        Dominique Martinet <asmadeus@...ewreck.org>,
        Christian Schoenebeck <linux_oss@...debyte.com>,
        David Howells <dhowells@...hat.com>,
        Marc Dionne <marc.dionne@...istor.com>,
        Xiubo Li <xiubli@...hat.com>,
        Ilya Dryomov <idryomov@...il.com>,
        Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@....nz>,
        Ronnie Sahlberg <lsahlber@...hat.com>,
        Shyam Prasad N <sprasad@...rosoft.com>,
        Tom Talpey <tom@...pey.com>,
        Christine Caulfield <ccaulfie@...hat.com>,
        David Teigland <teigland@...hat.com>,
        Chuck Lever <chuck.lever@...cle.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Bob Peterson <rpeterso@...hat.com>,
        Andreas Gruenbacher <agruenba@...hat.com>,
        Namjae Jeon <linkinjeon@...nel.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Anna Schumaker <anna@...nel.org>,
        Mark Fasheh <mark@...heh.com>,
        Joel Becker <jlbec@...lplan.org>,
        Joseph Qi <joseph.qi@...ux.alibaba.com>,
        Mike Marshall <hubcap@...ibond.com>,
        Martin Brandenburg <martin@...ibond.com>,
        "Darrick J. Wong" <djwong@...nel.org>, hch@....de,
        linux-kernel@...r.kernel.org, v9fs-developer@...ts.sourceforge.net,
        linux-afs@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
        ceph-devel@...r.kernel.org, linux-cifs@...r.kernel.org,
        samba-technical@...ts.samba.org, cluster-devel@...hat.com,
        linux-nfs@...r.kernel.org, ocfs2-devel@....oracle.com,
        devel@...ts.orangefs.org, linux-xfs@...r.kernel.org
Subject: Re: [PATCH] filelock: move file locking definitions to separate
 header file

On Fri, 2022-11-25 at 16:44 +0000, Al Viro wrote:
> On Fri, Nov 25, 2022 at 08:23:45AM -0500, Jeff Layton wrote:
> 
> > I left it in fs.h for now. Some of the file_operations prototypes need
> > that typedef, and I figure that anyone who is including filelock.h will
> > almost certainly need to include fs.h anyway. We could move it into a
> > separate header too, but it's probably not worth it.
> > 
> > HCH mentioned years ago though that we should just get rid of fl_owner_t
> > altogether and just use 'void *'. I didn't do it at the time because I
> > was focused on other changes, but this might be a good time to change
> > it.
> 
> Might be...
> 
> > > > +extern void show_fd_locks(struct seq_file *f,
> > > > +			 struct file *filp, struct files_struct *files);
> > > 
> > > If anything, that would be better off as fl_owner_t...  Again, a separate
> > > patch.
> > 
> > I'm not sure what you mean here. This prototype hasn't changed, and is
> > only called from procfs.
> 
> Take a look at that function and its caller.  The use of 'files' argument there
> is (and can be) only as an opaque pointer to be compared to ->fl_owner; at that
> point it might be pointing to freed memory, for all we know (and give false
> positives if already reused).

Ok. What we want this function to do is show any traditional POSIX or
OFD locks that were set on a particular file. The logic in
__show_fd_locks looks right, but you're correct that we don't want
anyone dereferencing those pointers in that codepath.

Note too that this info is not wholly reliable. POSIX locks can merge
with other locks that were set within the same process (same
files_struct) but on different fds.

I think we want to get rid of fl_owner_t anyway. Maybe we should replace
it with an unsigned long instead of void * to discourage anyone from
trying to dereference those pointers?

> TBH, I'd never been able to finish the audit of files_struct pointers passed
> into locks subsystem; there definitely are moments when code from fs/locks.c
> is dealing with pointers to already freed instances - show_fd_locks() at the
> very least.  They are not dereferenced, but beyond that...

Yeah. In general, we try to ensure that locks are torn down before the
file with which it is associated, but with some of the delayed freeing,
they can outlive the file at times. For example:

    https://tracker.ceph.com/issues/57986

-- 
Jeff Layton <jlayton@...nel.org>