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  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]
Date:   Fri, 6 Mar 2020 20:45:23 +0000
From:   Al Viro <>
To:     Miklos Szeredi <>
Cc:     Ian Kent <>, David Howells <>,
        Christian Brauner <>,
        James Bottomley <>,
        Steven Whitehouse <>,
        Miklos Szeredi <>,
        Christian Brauner <>,
        Jann Horn <>,
        "Darrick J. Wong" <>,
        Linux API <>,
        linux-fsdevel <>,
        lkml <>,
        Greg Kroah-Hartman <>
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver

On Fri, Mar 06, 2020 at 08:38:44PM +0000, Al Viro wrote:
> On Fri, Mar 06, 2020 at 08:37:05PM +0000, Al Viro wrote:
> > You are misreading mntput_no_expire(), BTW - your get_mount() can
> > bloody well race with umount(2), hitting the moment when we are done
> > figuring out whether it's busy but hadn't cleaned ->mnt_ns (let alone
> > set MNT_DOOMED) yet.  If somebody calls umount(2) on a filesystem that
> > is not mounted anywhere else, they are not supposed to see the sucker
> > return 0 until the filesystem is shut down.  You break that.
> While we are at it, d_alloc_parallel() requires i_rwsem on parent held
> at least shared.

Egads...  Let me see if I got it right - you are providing procfs symlinks
to objects on the internal mount of that thing.  And those objects happen
to be directories, so one can get to their parent that way.  Or am I misreading
that thing?

Powered by blists - more mailing lists