Received-SPF: pass (google.com: domain of linux-kernel+bounces-187859-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells <dhowells@redhat.com>
In-Reply-To: <Zk9y21FktxyLGqDJ@codewreck.org>
References: <Zk9y21FktxyLGqDJ@codewreck.org> <00000000000092914806191382ac@google.com> <580959.1716475058@warthog.procyon.org.uk>
To: asmadeus@codewreck.org
Cc: dhowells@redhat.com,
    syzbot <syzbot+d7c7a495a5e466c031b6@syzkaller.appspotmail.com>,
    brauner@kernel.org, hdanton@sina.com, linux-kernel@vger.kernel.org,
    syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [v9fs?] KASAN: slab-use-after-free Read in p9_fid_destroy
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <641238.1716487625.1@warthog.procyon.org.uk>
Date: Thu, 23 May 2024 19:07:05 +0100
Message-ID: <641239.1716487625@warthog.procyon.org.uk>

asmadeus@codewreck.org wrote:

> > There's a problem in 9p's interaction with netfslib whereby a crash occurs
> > because the 9p_fid structs get forcibly destroyed during client teardown
> > (without paying attention to their refcounts) before netfslib has finished
> > with them.  However, it's not a simple case of deferring the clunking that
> > p9_fid_put() does as that requires the client.
> 
> "as that requires the client" doesn't parse

"... as that requires the p9_client record to still be present."?

David