All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cen Zhang (Microsoft)" <blbllhy@gmail.com>
To: sashiko-bot@kernel.org
Cc: blbllhy@gmail.com, linux-can@vger.kernel.org, mailhol@kernel.org,
	mkl@pengutronix.de, o.rempel@pengutronix.de,
	sashiko-reviews@lists.linux.dev, socketcan@hartkopp.net,
	AutonomousCodeSecurity@microsoft.com, xmei5@asu.edu
Subject: Re: [PATCH net] can: kvaser_usb: validate command format before parsing in hydra receive path
Date: Mon, 24 Aug 2026 22:41:10 -0400	[thread overview]
Message-ID: <20260825024110.12021-1-blbllhy@gmail.com> (raw)
In-Reply-To: <20260824215344.6D5751F000E9@smtp.kernel.org>

On Wed, Aug 19, 2026 at 03:10:26PM +0000, sashiko-bot@kernel.org wrote:
> This is a pre-existing issue, but do these error paths need to reset
> usb_rx_leftover_len to 0?

Yes. Otherwise the next transfer retries the same malformed leftover and
fails again. I will clear usb_rx_leftover_len before returning and send
v2.

> This isn't a bug introduced by this patch, but does the parser loop
> trust cmd_len without validating that it meets the minimum structural
> size expected by the command handler?

Yes. The generic parser validates framing, but not each command's minimum
structural length. That is a separate command-dispatch validation issue
and is outside the scope of this patch.

Thanks,
Cen

  reply	other threads:[~2026-08-25  2:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 21:40 [PATCH net v2] can: kvaser_usb: validate command format before parsing in hydra receive path Cen Zhang (Microsoft)
2026-08-24 21:53 ` sashiko-bot
2026-08-25  2:41   ` Cen Zhang (Microsoft) [this message]
2026-08-25  2:50     ` Cen Zhang (Microsoft)
  -- strict thread matches above, loose matches on Subject: below --
2026-08-19 14:56 [PATCH net] " Cen Zhang (Microsoft)
2026-08-19 15:10 ` sashiko-bot
2026-08-24 21:35   ` Cen Zhang (Microsoft)

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=20260825024110.12021-1-blbllhy@gmail.com \
    --to=blbllhy@gmail.com \
    --cc=AutonomousCodeSecurity@microsoft.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=o.rempel@pengutronix.de \
    --cc=sashiko-bot@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=socketcan@hartkopp.net \
    --cc=xmei5@asu.edu \
    /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.