mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: mkl@pengutronix.de
Cc: mailhol@kernel.org, pfink@christ-es.de, eric@evenchick.com,
	max@schneidersoft.net, wg@grandegger.com, kernel@pengutronix.de,
	linux-can@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, kuba@kernel.org
Subject: Re: [PATCH can-next v6 2/6] can: gs_usb: gs_can_start_xmit(): don't leak uninitialized memory over USB
Date: Sat, 14 Nov 2026 23:44:53 +0000	[thread overview]
Message-ID: <179469989360.488853.2267495586582678566@kernel.org> (raw)
In-Reply-To: <20261113-gs_usb-fixes-v6-2-0c039e1bfd74@pengutronix.de>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] can: gs_usb: inaccurate Fixes: trailer in commit message

--

> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
> --- a/drivers/net/can/usb/gs_usb.c
> +++ b/drivers/net/can/usb/gs_usb.c
> @@ -861,7 +861,7 @@ static netdev_tx_t gs_can_start_xmit(struct sk_buff *skb,
>  	if (!urb)
>  		goto nomem_urb;
>  
> -	hf = kmalloc(dev->hf_size_tx, GFP_ATOMIC);
> +	hf = kzalloc(dev->hf_size_tx, GFP_ATOMIC);
>  	if (!hf)
>  		goto nomem_hf;
>  
>

[Severity: Low]
The Fixes: tag points at 26949ac935e3 ("can: gs_usb: add CAN-FD
support"). As far as I can tell, the leak in gs_can_start_xmit() is
older than the CAN-FD support.

The original driver, d08e973a77d1 ("can: gs_usb: Added support for the
GS_USB CAN devices"), already allocated hf with usb_alloc_coherent()
without __GFP_ZERO. It copied only cf->can_dlc bytes into the 8 byte
hf->data array and then submitted the full sizeof(*hf) buffer. So
whenever the DLC was below 8, the tail of hf->data went out over USB
uninitialized.

The kmalloc() call changed here was added later by 62f102c0d156
("can: gs_usb: remove dma allocations"). That commit kept the same
behaviour.

This patch is tagged for stable. With the tag pointing at the CAN-FD
commit, stable trees that have the classic CAN variant of the leak but
not 26949ac935e3 may never pick up a fix.

Should this be Fixes: d08e973a77d1 instead? The one-liner will not
apply before 62f102c0d156, so older trees would need a separate
backport against usb_alloc_coherent(). Would you rather list both
commits, or add a note for the stable maintainers?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261113-gs_usb-fixes-v6-0-0c039e1bfd74%40pengutronix.de

  reply	other threads:[~2026-11-14 23:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 10:08 [PATCH can-next v6 0/6] gs_usb: fixes Marc Kleine-Budde
2026-11-13 10:08 ` [PATCH can-next v6 1/6] can: gs_usb: gs_make_candev(): check can_rx_offload_add_manual() return value Marc Kleine-Budde
2026-11-14 23:44   ` netdev-bot+sashiko
2026-11-13 10:08 ` [PATCH can-next v6 2/6] can: gs_usb: gs_can_start_xmit(): don't leak uninitialized memory over USB Marc Kleine-Budde
2026-11-14 23:44   ` netdev-bot+sashiko [this message]
2026-11-13 10:08 ` [PATCH can-next v6 3/6] can: gs_usb: gs_usb_probe(): init netdev completely before register_candev() Marc Kleine-Budde
2026-11-13 10:08 ` [PATCH can-next v6 4/6] can: gs_usb: gs_usb_receive_bulk_callback(): check for overflow flag if SKB allocation fails Marc Kleine-Budde
2026-11-13 10:08 ` [PATCH can-next v6 5/6] can: gs_usb: gs_usb_receive_bulk_callback(): add missing call to can_rx_offload_irq_finish Marc Kleine-Budde
2026-11-13 10:08 ` [PATCH can-next v6 6/6] can: gs_usb: fix hardware timestamp state for mixed channels Marc Kleine-Budde
2026-11-14 23:44   ` netdev-bot+sashiko

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=179469989360.488853.2267495586582678566@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=eric@evenchick.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=max@schneidersoft.net \
    --cc=mkl@pengutronix.de \
    --cc=pfink@christ-es.de \
    --cc=stable@vger.kernel.org \
    --cc=wg@grandegger.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

all inboxes | Powered by JetHome®