netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Foster Snowhill <forst@pen.gy>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Georgi Valkov <gvalkov@gmail.com>,
	Simon Horman <horms@kernel.org>, Oliver Neukum <oneukum@suse.com>,
	netdev@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH net v4 0/7] usbnet: ipheth: prevent OoB reads of NDP16
Date: Mon, 13 Jan 2025 12:52:32 -0800	[thread overview]
Message-ID: <20250113125232.733fb088@kernel.org> (raw)
In-Reply-To: <e587e1c7-a2ff-4e28-9e25-b57f68545134@pen.gy>

On Mon, 13 Jan 2025 02:48:58 +0100 Foster Snowhill wrote:
> Thank you very much for the review!
> 
> I went through the series again, noticed a couple minor things I think
> I should fix:
> 
> * Patch 1/7 ("usbnet: ipheth: break up NCM header size computation")
>   [p1] introduces two new preprocessor constants. Only one of them is
>   used (the other one is intermediate, for clarity), and the usage is
>   all the way in patch 6/7 ("usbnet: ipheth: fix DPE OoB read") [p6].
>   I'd like to move the constant introduction patch right before the
>   patch that uses one of them. There's no good reason they're spread
>   out like they are in v4.
> * Commit message in patch 5/7 ("usbnet: ipheth: refactor NCM datagram
>   loop") [p5] has a stray paragraph starting with "Fix an out-of-bounds
>   DPE read...". This needs to be removed.
> 
> I'd like to get this right. I'll make the changes above, add Cc stable,
> re-test all patches in sequence, and submit v5 soon. As this will be
> a different revision, I figure I can't formally apply your "Reviewed-by"
> anymore, the series may need another look once I post v5.

The opinions on the exact rules differ but you can definitely add my tag
on the patches which won't change.

> Also I have some doubts about patch 7/7 [p7] with regards to its
> applicability to backporting to older stable releases. This only adds a
> documentation comment, without fixing any particular issue. Doesn't
> sound like something that should go into stable. But maybe fine if it's
> part of a series?

Yes, it's fine as part of the series.

> I can also add that text in a commit message rather
> than the source code of the driver itself, or even just keep it in the
> cover letter. Do you have any opinion on this?

Maybe it's because I don't work with USB networking much but to me
the comment was useful.

      reply	other threads:[~2025-01-13 20:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-05  1:01 [PATCH net v4 0/7] usbnet: ipheth: prevent OoB reads of NDP16 Foster Snowhill
2025-01-05  1:01 ` [PATCH net v4 1/7] usbnet: ipheth: break up NCM header size computation Foster Snowhill
2025-01-05  1:01 ` [PATCH net v4 2/7] usbnet: ipheth: fix possible overflow in DPE length check Foster Snowhill
2025-01-05  1:01 ` [PATCH net v4 3/7] usbnet: ipheth: check that DPE points past NCM header Foster Snowhill
2025-01-05  1:01 ` [PATCH net v4 4/7] usbnet: ipheth: use static NDP16 location in URB Foster Snowhill
2025-01-05  7:46   ` Greg KH
2025-01-05  1:01 ` [PATCH net v4 5/7] usbnet: ipheth: refactor NCM datagram loop Foster Snowhill
2025-01-05  1:01 ` [PATCH net v4 6/7] usbnet: ipheth: fix DPE OoB read Foster Snowhill
2025-01-05  7:46   ` Greg KH
2025-01-05  1:01 ` [PATCH net v4 7/7] usbnet: ipheth: document scope of NCM implementation Foster Snowhill
2025-01-08  1:31 ` [PATCH net v4 0/7] usbnet: ipheth: prevent OoB reads of NDP16 Jakub Kicinski
2025-01-13  1:48   ` Foster Snowhill
2025-01-13 20:52     ` Jakub Kicinski [this message]

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=20250113125232.733fb088@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=forst@pen.gy \
    --cc=gvalkov@gmail.com \
    --cc=horms@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=pabeni@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).