linux-kernel - Re: [PATCH] fs/9p: Compare qid.path in v9fs_test

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: <20170308154610.59a563a3@duuni>
Date:   Wed, 8 Mar 2017 15:46:10 +0200
From:   Tuomas Tynkkynen <tuomas@...era.com>
To:     Alexander Viro <viro@...iv.linux.org.uk>
CC:     <linux-fsdevel@...r.kernel.org>,
        Eric Van Hensbergen <ericvh@...il.com>,
        <v9fs-developer@...ts.sourceforge.net>,
        <linux-kernel@...r.kernel.org>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.vnet.ibm.com>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH] fs/9p: Compare qid.path in v9fs_test_inode

On Wed, 22 Feb 2017 02:06:29 +0200
Tuomas Tynkkynen <tuomas@...era.com> wrote:

> Commit fd2421f54423 ("fs/9p: When doing inode lookup compare qid details
> and inode mode bits.") transformed v9fs_qid_iget() to use iget5_locked()
> instead of iget_locked(). However, the test() callback is not checking
> fid.path at all, which means that a lookup in the inode cache can now
> accidentally locate a completely wrong inode from the same inode hash
> bucket if the other fields (qid.type and qid.version) match.
> 

Al, does this sound sensible? (or if there is someone else picking up 9p
patches, let me know).

Thanks!

- Tuomas