Linux USB
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wei Jie Law" <law.wei.jie@gt.tech.gov.sg>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH net 2/2] net: usb: pegasus: check rx pkt_len against the received length
Date: Thu, 15 Oct 2026 02:53:38 +0000	[thread overview]
Message-ID: <sashiko-outbox-172186@kernel.org> (raw)
In-Reply-To: <20261014025307.25233-3-law.wei.jie@gt.tech.gov.sg>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] net: usb: pegasus: uninitialized memory read in eth_type_trans on short packets
--

commit 35f61a0523edaec588769ea008eada12f3c5521e
Author: Wei Jie Law <law.wei.jie@gt.tech.gov.sg>

net: usb: pegasus: check rx pkt_len against the received length

This commit modifies the receive path in the pegasus driver to drop frames
where the claimed packet length plus the receive header offset exceeds the
actual received byte count. It prevents packets from being processed with
uninitialized buffer data when a short transfer claims a long frame.

> diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
> index 7c7d6b69998f2..7bc9312eaa9ec 100644
> --- a/drivers/net/usb/pegasus.c
> +++ b/drivers/net/usb/pegasus.c
> @@ -520,10 +520,11 @@ static void read_bulk_callback(struct urb *urb)
>  	}
>  
>  	/*
> -	 * If the packet is unreasonably long, quietly drop it rather than
> -	 * kernel panicing by calling skb_put.
> +	 * If the packet is longer than what was actually received, quietly
> +	 * drop it rather than kernel panicing by calling skb_put or passing
> +	 * up stale buffer contents. count is at most PEGASUS_MTU.
>  	 */
> -	if (pkt_len > PEGASUS_MTU - rx_offset)
> +	if (pkt_len + rx_offset > count)

[Severity: Medium]
Does this length validation adequately prevent undersized packets from passing?

If a small transfer arrives with count = 4, pkt_len = 0, and rx_offset = 2,
the check (pkt_len + rx_offset > count) evaluates to false since 0 + 2 <= 4,
allowing the packet to proceed.

The function then calls skb_put() and passes the buffer to eth_type_trans()
further down in read_bulk_callback():

	skb_put(pegasus->rx_skb, pkt_len);
	pegasus->rx_skb->protocol = eth_type_trans(pegasus->rx_skb, net);

Because eth_type_trans() unconditionally reads ETH_HLEN (14 bytes) to parse
the MAC header, providing it with an empty or undersized socket buffer
results in an uninitialized memory read of 12 bytes.

Could an additional check be added to ensure the calculated pkt_len is at
least ETH_HLEN before passing the packet up the stack?

>  		goto goon;
>  
>  	/*

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014025307.25233-1-law.wei.jie@gt.tech.gov.sg?part=2

      reply	other threads:[~2026-10-15  2:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  2:53 [PATCH net 0/2] net: usb: pegasus: fix receive length handling Wei Jie Law
2026-10-14  2:53 ` [PATCH net 1/2] net: usb: pegasus: do not advance rx_skb->data on dropped frames Wei Jie Law
2026-10-15  2:53   ` sashiko-bot
2026-10-14  2:53 ` [PATCH net 2/2] net: usb: pegasus: check rx pkt_len against the received length Wei Jie Law
2026-10-15  2:53   ` sashiko-bot [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=sashiko-outbox-172186@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=law.wei.jie@gt.tech.gov.sg \
    --cc=linux-usb@vger.kernel.org \
    --cc=sashiko-reviews@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