linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <20240923100508.GA32066@willie-the-truck>
Date: Mon, 23 Sep 2024 11:05:10 +0100
From: Will Deacon <will@...nel.org>
To: ericvh@...nel.org
Cc: lucho@...kov.net, asmadeus@...ewreck.org, oss@...debyte.com,
	v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org, oleg@...hat.com,
	keirf@...gle.com
Subject: VFS regression with 9pfs ("Lookup would have caused loop")

Hi Eric,

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.

Cheers,

Will