From: Demi Marie Obenour <demiobenour@gmail.com>
To: Ariadne Conill <ariadne@ariadne.space>, v9fs@lists.linux.dev
Cc: xen-devel@lists.xenproject.org, asmadeus@codewreck.org,
linux_oss@crudebyte.com, lucho@ionkov.net, ericvh@kernel.org,
Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Alex Zenla <alex@edera.dev>
Subject: Re: [PATCH] 9p/xen: mark 9p transport device as closing when removing it
Date: Tue, 9 Dec 2025 05:41:39 -0500 [thread overview]
Message-ID: <409cccec-15dd-4e80-ba56-f0bba12772cb@gmail.com> (raw)
In-Reply-To: <20251208195155.27473-1-ariadne@ariadne.space>
[-- Attachment #1.1.1: Type: text/plain, Size: 1839 bytes --]
On 12/8/25 14:51, Ariadne Conill wrote:
> We need to do this so that we can signal to the other end that the
> device is being removed, so that it will release its claim on the
> underlying memory allocation. Otherwise releasing the grant-table
> entries is deferred resulting in a kernel oops since the pages have
> already been freed.
I don't think this is sufficient. The backend can simply refuse
to release the grants. The frontend needs to ensure that the pages
are not freed until the grant table entries are freed. Right now,
the backend can cause a use-after-free in the frontend, and my
understanding of the Xen Project's security policy is that this is
a security vulnerability in the frontend code.
My instinct is that the core Xen code should take a reference on
each page before granting it to another domain, and not release that
reference until the pages are no longer granted. This should prevent
any use-after-free problems if I understand Linux core MM correctly.
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Fixes: 71ebd71921e45 ("xen/9pfs: connect to the backend")
> Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
> Signed-off-by: Alex Zenla <alex@edera.dev>
> ---
> net/9p/trans_xen.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> index b9ff69c7522a..cde283c42dc6 100644
> --- a/net/9p/trans_xen.c
> +++ b/net/9p/trans_xen.c
> @@ -312,6 +312,7 @@ static void xen_9pfs_front_remove(struct xenbus_device *dev)
> {
> struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev);
>
> + xenbus_switch_state(dev, XenbusStateClosing);
> dev_set_drvdata(&dev->dev, NULL);
> xen_9pfs_front_free(priv);
> }
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-12-09 10:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 19:51 [PATCH] 9p/xen: mark 9p transport device as closing when removing it Ariadne Conill
2025-12-09 10:41 ` Demi Marie Obenour [this message]
2025-12-09 17:09 ` Ariadne Conill
2025-12-09 17:12 ` Demi Marie Obenour
2025-12-09 17:18 ` Ariadne Conill
2025-12-18 8:14 ` Jürgen Groß
2025-12-20 2:02 ` Demi Marie Obenour
2025-12-09 20:45 ` Marek Marczykowski-Górecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=409cccec-15dd-4e80-ba56-f0bba12772cb@gmail.com \
--to=demiobenour@gmail.com \
--cc=alex@edera.dev \
--cc=ariadne@ariadne.space \
--cc=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=jgross@suse.com \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=sstabellini@kernel.org \
--cc=v9fs@lists.linux.dev \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox