From: asmadeus@codewreck.org
To: Danis Jiang <danisjiang@gmail.com>
Cc: ericvh@kernel.org, lucho@ionkov.net, linux_oss@crudebyte.com,
v9fs@lists.linux.dev, linux-kernel@vger.kernel.org,
security@kernel.org, stable@vger.kernel.org,
Mirsad Todorovac <mtodorovac69@gmail.com>
Subject: Re: [PATCH] net/9p: Fix buffer overflow in USB transport layer
Date: Tue, 17 Jun 2025 13:11:51 +0900 [thread overview]
Message-ID: <aFDrBwql20jYrvp1@codewreck.org> (raw)
In-Reply-To: <CAHYQsXR43MGM826eHtEkmH4X2bM-amM29A38XUj+hMbNF2vDJQ@mail.gmail.com>
Danis Jiang wrote on Tue, Jun 17, 2025 at 11:01:40AM +0800:
>>> Add validation in usb9pfs_rx_complete() to ensure req->actual does not
>>> exceed the buffer capacity before copying data.
>>
>> Thanks for this check!
>>
>> Did you reproduce this or was this static analysis found?
>> (to knowi if you tested wrt question below)
>
> I found this by static analysis.
Ok.
>> I still haven't gotten around to setting up something to test this, and
>> even less the error case, but I'm not sure a single put is enough --
>> p9_client_cb does another put.
>> Conceptually I think it's better to mark the error and move on
>> e.g. (not even compile tested)
>> ```
>> int status = REQ_STATUS_RCVD;
>>
>> [...]
>>
>> if (req->actual > p9_rx_req->rc.capacity) {
>> dev_err(...)
>> req->actual = 0;
>> status = REQ_STATUS_ERROR;
>> }
>>
>> memcpy(..)
>>
>> p9_rx_req->rc.size = req->actual;
>>
>> p9_client_cb(usb9pfs->client, p9_rx_req, status);
>> p9_req_put(usb9pfs->client, p9_rx_req);
>>
>> complete(&usb9pfs->received);
>> ```
>> (I'm not sure overriding req->actual is allowed, might be safer to use
>> an intermediate variable like status instead)
>>
>> What do you think?
>
> Yes, I think your patch is better, my initial patch forgot p9_client_cb.
Ok, let's go with that then.
Would you like to resend "my" version, or should I do it (and
refer to your patch as Reported-by)?
Also if you resend let's add Mirsad Todorovac <mtodorovac69@gmail.com> too Ccs,
I've added him now.
(Mirsad, please check lore for full context if quote wasn't enough:
https://lkml.kernel.org/r/20250616132539.63434-1-danisjiang@gmail.com
)
Thanks,
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2025-06-17 4:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-16 13:25 [PATCH] net/9p: Fix buffer overflow in USB transport layer Yuhao Jiang
2025-06-16 23:00 ` asmadeus
2025-06-17 3:01 ` Danis Jiang
2025-06-17 4:11 ` asmadeus [this message]
2025-06-17 4:29 ` Danis Jiang
-- strict thread matches above, loose matches on Subject: below --
2025-06-16 13:21 Yuhao Jiang
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=aFDrBwql20jYrvp1@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=danisjiang@gmail.com \
--cc=ericvh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=mtodorovac69@gmail.com \
--cc=security@kernel.org \
--cc=stable@vger.kernel.org \
--cc=v9fs@lists.linux.dev \
/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