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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4966de3e-6900-481c-8f6b-00e37cebab7e@leemhuis.info>
Date: Tue, 15 Oct 2024 20:07:10 +0200
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Will Deacon <will@...nel.org>, ericvh@...nel.org
Cc: lucho@...kov.net, asmadeus@...ewreck.org,
 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")

Hi Will! Top-posting for once, to make this easily accessible to everyone.

Thx for bringing this to my attention. I had hoped that Eric might reply
and waited a bit, but that did not happen. I kind of expected that, as
he seems to be  somewhat afk, as the last mail from him on lore is from
mid-September; and in the weeks before that he did not post much either.
Hmmm. :-/

CCed Christian and Al, maybe they might be able to help directly or
indirectly somehow. If not, we likely need to get Linus involved to
decide if we want to at least temporarily revert the changes you mentioned.

Ciao, Thorsten

On 09.10.24 17:34, Will Deacon wrote:
> On Mon, Sep 23, 2024 at 11:05:08AM +0100, Will Deacon wrote:
>>
>> I'm trying to use kvmtool to run a simple guest under an Android host
>> but, for v6.9+ guest kernels, 'init' reliably fails to run from a 9pfs
>> mount because VFS emits this error:
>>
>>   | VFS: Lookup of 'com.android.runtime' in 9p 9p would have caused loop
>>
>> The host directory being shared is a little odd, as it has symlinks out
>> to other mount points. In the guest, /apex is a symlink to /host/apex.
>> On the host, /apex/com.android.runtime is a mounted loopback device:
>>
>> /dev/block/loop13 on /apex/com.android.runtime type ext4 (ro,dirsync,seclabel,nodev,noatime)
>>
>> This used to work prior to 724a08450f74 ("fs/9p: simplify iget to remove
>> unnecessary paths") and it looks like Oleg ran into something similar
>> before:
>>
>>   https://lore.kernel.org/all/20240408141436.GA17022@redhat.com/
>>
>> although he worked around it by driving QEMU with different options.
>>
>> I can confirm that reverting the following commits gets mainline guests
>> working again for me:
>>
>> 	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"
>>
>> Do you have any better ideas? I'm happy to test anything you might have,
>> since this is 100% reproducible on my setup.
> 
> Adding the regression tracker as I've not heard anything back on this :(
> #regzbot introduced: 724a08450f74