All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Cc: v9fs@lists.linux.dev, "Eric Van Hensbergen" <ericvh@kernel.org>,
	"Latchesar Ionkov" <lucho@ionkov.net>,
	"Christian Schoenebeck" <linux_oss@crudebyte.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	"Yuxiang Yang" <yangyx22@mails.tsinghua.edu.cn>,
	"Ao Wang" <wangao@seu.edu.cn>, "Xuewei Feng" <fengxw06@126.com>,
	"Qi Li" <qli01@tsinghua.edu.cn>, "Ke Xu" <xuke@tsinghua.edu.cn>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Jürgen Groß" <jgross@suse.com>
Subject: Re: [PATCH] 9p/xen: drain response work after unbinding IRQ
Date: Sun, 13 Sep 2026 22:10:21 +0900	[thread overview]
Message-ID: <aqagvTnrIOGl8nfi@codewreck.org> (raw)
In-Reply-To: <20260609155202.1706-1-zhaoyz24@mails.tsinghua.edu.cn>

Yizhou Zhao wrote on Tue, Jun 09, 2026 at 11:52:01PM +0800:
> commit ea4f1009408e ("9p/xen : Fix use after free bug in
> xen_9pfs_front_remove due to race condition") added cancel_work_sync()
> to keep xen_9pfs_front_free() from freeing a ring while
> p9_xen_response() is still running.
> 
> The work is currently drained before the event channel IRQ is unbound.
> That leaves a race window where xen_9pfs_front_event_handler() can run
> after cancel_work_sync() returns and queue p9_xen_response() again.  The
> following unbind_from_irqhandler() synchronizes with the IRQ handler, but
> it does not cancel work that the handler already queued.  The teardown
> can then free the ring and private data while the response work remains
> pending, and the worker later dereferences ring->priv and priv->client.
> 
> Unbind the event channel IRQ before draining the work.  Once the IRQ is
> unbound, no new response work can be queued by the backend event channel,
> and cancel_work_sync() waits for any work that was queued before or
> during the unbind.  It is then safe to release the ring resources.
> 
> Fixes: ea4f1009408e ("9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition")
> Cc: stable@vger.kernel.org
> Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
> Reported-by: Ao Wang <wangao@seu.edu.cn>
> Reported-by: Xuewei Feng <fengxw06@126.com>
> Reported-by: Qi Li <qli01@tsinghua.edu.cn>
> Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
> Assisted-by: GLM:GLM-5.1
> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>

This one makes sense to me and I've picked it up, but I think
"9p/xen: fix use-after-free in p9_xen_request"[1] adding a refcount to
the front_priv is too much complexity vs. my understanding of the
current threat model -- I can pick it up if someome who understands xen
better than me has a proper look.

Stefano or Jürgen if you care / have time?

[1] https://lore.kernel.org/r/20260529103416.81378-1-zhaoyz24@mails.tsinghua.edu.cn

Thanks,

> ---
>  net/9p/trans_xen.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> index f9fb2db7a066..73c75fbdfa21 100644
> --- a/net/9p/trans_xen.c
> +++ b/net/9p/trans_xen.c
> @@ -281,14 +281,14 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
>  		for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) {
>  			struct xen_9pfs_dataring *ring = &priv->rings[i];
>  
> -			cancel_work_sync(&ring->work);
> -
>  			if (!ring->intf)
>  				break;
>  			if (ring->irq >= 0) {
>  				unbind_from_irqhandler(ring->irq, ring);
>  				ring->irq = -1;
>  			}
> +			cancel_work_sync(&ring->work);
> +
>  			if (ring->data.in) {
>  				for (j = 0; j < (1 << ring->intf->ring_order);
>  				     j++) {

-- 
Dominique Martinet | Asmadeus

  reply	other threads:[~2026-09-13 13:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09 15:52 [PATCH] 9p/xen: drain response work after unbinding IRQ Yizhou Zhao
2026-09-13 13:10 ` Dominique Martinet [this message]
2026-10-08 10:42   ` Juergen Gross
2026-10-28 21:05     ` Dominique Martinet

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=aqagvTnrIOGl8nfi@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=ericvh@kernel.org \
    --cc=fengxw06@126.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=qli01@tsinghua.edu.cn \
    --cc=sstabellini@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=v9fs@lists.linux.dev \
    --cc=wangao@seu.edu.cn \
    --cc=xuke@tsinghua.edu.cn \
    --cc=yangyx22@mails.tsinghua.edu.cn \
    --cc=zhaoyz24@mails.tsinghua.edu.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.