From: Michael Grzeschik <mgr@kernel.org>
To: Dominique Martinet <asmadeus@codewreck.org>
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,
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>,
Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Subject: Re: [PATCH] net/9p/usbg: Fix use-after-free on usb9pfs_clear_tx
Date: Tue, 15 Sep 2026 08:54:22 +0200 [thread overview]
Message-ID: <aqjflEL_79A95MGc@line.checkpat.ch> (raw)
In-Reply-To: <aqZichSBFZgqFn8F@codewreck.org>
Hi Dominique
On Sun, Sep 13, 2026 at 05:44:34PM +0900, Dominique Martinet wrote:
> I'm honestly not quite sure what to do with this and others UAF usb9pfs
> patches -- you acked the first one I replied to, and the tag match is
> obviously correct so I picked these two, but I'd like your opinion on
> the rest for two reasons:
> - There seem to be plenty of rough edges around usb9pfs, and frankly I
> don't consider this a trust boundary (the usecase being developping
> embedded devices, you trust the server fully, so whatever happens
> in corner cases doesn't matter)
I agree that the edges are there and need to be fixed.
> - You had a rework in progress (before leaving Pengutronix, which I can
> totally understand you don't have time or want to keep carrying going
> forward, but is someone else from Pengutronix taking your place?)
I am actually carrying to improve the series. I just now got some time
and started to build an setup where I can easily test further changes.
Also my leftover patches are also tested and ready for updates on the
list.
> For all I know this is also correct, but I'm not sure slapping a bandaid
> is the way to go, so I'd really appreciate if you could have a look at
> this[1] and "net/9p/usbg: clear stale request context after abort"[2]
> [1] https://lore.kernel.org/r/20260529081026.77732-1-zhaoyz24@mails.tsinghua.edu.cn
> [2] https://lore.kernel.org/r/20260802152148.810390-1-marsy12010123@gmail.com
>
> If you tell me to pick them up I will, and if I don't hear back from you
> I'll take another look hopefully before the 7.4 deadline, but I honestly
> don't have enough time for this so the most likely outcome will be
> /dev/null
I just acked the two and rebased my further work on them.
> Thanks (and sorry Yizhou Zhao / Chengfeng Ye)
Thank you for caring and sorry for the long delay. Things are in
steady motion, but will hopefully smooth out soon. ;)
> --
> Dominique
next prev parent reply other threads:[~2026-09-15 6:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 8:10 [PATCH] net/9p/usbg: Fix use-after-free on usb9pfs_clear_tx Yizhou Zhao
2026-09-13 8:44 ` Dominique Martinet
2026-09-15 6:54 ` Michael Grzeschik [this message]
2026-09-15 7:09 ` Dominique Martinet
2026-09-15 6:51 ` Michael Grzeschik
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=aqjflEL_79A95MGc@line.checkpat.ch \
--to=mgr@kernel.org \
--cc=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=fengxw06@126.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=qli01@tsinghua.edu.cn \
--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.