public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
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

  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