linux-kernel - Re: VFS regression with 9pfs ("Lookup would have caused loop")

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <26f5505f-185a-43a9-8eda-4fb36c0f07c4@leemhuis.info>
Date: Wed, 23 Oct 2024 09:22:26 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Dominique Martinet <asmadeus@...ewreck.org>, Will Deacon
 <will@...nel.org>, ericvh@...nel.org
Cc: lucho@...kov.net, Christian Brauner <brauner@...nel.org>,
 Alexander Viro <viro@...iv.linux.org.uk>, oss@...debyte.com,
 v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org, oleg@...hat.com,
 keirf@...gle.com, regressions@...ts.linux.dev
Subject: Re: VFS regression with 9pfs ("Lookup would have caused loop")

On 23.10.24 01:00, Dominique Martinet wrote:
> Will Deacon wrote on Tue, Oct 22, 2024 at 04:01:49PM +0100:
>
> [...]

Dominique, thx for taking the time to take care of this.

> I've also confirmed reverting the 4 commits listed by Will do fix both
> behaviors (along with a fscache warning when hitting the duplicate inode
> file, but that's expected):
>         724a08450f74 "fs/9p: simplify iget to remove unnecessary paths"
>         11763a8598f8 "fs/9p: fix uaf in in v9fs_stat2inode_dotl"
>         10211b4a23cf "fs/9p: remove redundant pointer v9ses"
>         d05dcfdf5e16 " fs/9p: mitigate inode collisions"
> [...]
> I think that's the sane thing to do, let's first go back to something
> that works and we can try again if/when someone has time - [...]
> 
> Thorsten, is there a preferred way reverts should be done?
> In this case it'd probably make sense to squash the 4 reverts in a
> single megarevert? At the very least getting anywhere in the middle with
> the uaf isn't something one would want... And they all made it in 6.9
> together so there's no benefit in splitting them for backport either.

Will might be the better person to ask, but since you asked me: I think
I've see a "megarevert" recently from the corner of my eye, but that
made me go "huh, that is unusual". My perception might wrong and in some
situations they might be a good idea. Not sure if this is one to to the
UAF. But that would only be relevant during a bisection or for everyone
stupid enough to backport only some of the reverts (if I understood you
right). I guess a proper patch description and a common Fixes: tag for
all four should prevent that.

Ciao, THorsten