From: Simon Horman <horms@kernel.org>
To: Wei Jie Law <law.wei.jie@gt.tech.gov.sg>
Cc: Petko Manolov <petkan@nucleusys.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, Wei Jie Law <98lawweijie@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH net v2 2/2] net: usb: pegasus: check rx pkt_len against the received length
Date: Mon, 26 Oct 2026 16:31:51 +0000 [thread overview]
Message-ID: <20261026163151.GC257209@horms.kernel.org> (raw)
In-Reply-To: <20261021020310.34045-3-law.wei.jie@gt.tech.gov.sg>
On Wed, Oct 21, 2026 at 10:03:10AM +0800, Wei Jie Law wrote:
> read_bulk_callback() takes the frame length from the device, from the
> receive header on the 0x8513 and from the trailing status bytes on the
> other chips, and only checks it against PEGASUS_MTU before passing that
> many bytes up the stack. In two cases the stack then uses bytes that the
> device did not send:
>
> - A device that sends a short transfer but claims a long frame gets the
> stale or uninitialized remainder of the receive skb delivered as
> packet data.
>
> - A device that claims a frame shorter than an Ethernet header gets
> past the check as well. eth_type_trans() takes pkt_type from h_dest
> and the protocol from h_proto without checking skb->len. If the
> transfer is also short, those come from bytes left in the skb by an
> earlier transfer, or from uninitialized memory.
>
> Drop frames shorter than ETH_HLEN, and frames whose claimed length, plus
> the 0x8513 header, does not fit in the bytes actually received, and
> count them as length errors. urb->actual_length never exceeds the
> PEGASUS_MTU sized transfer buffer, so this also covers the existing
> PEGASUS_MTU check. Valid Ethernet frames are at least 60 bytes long
> without the FCS, so they are not affected.
>
> Found by code review with LLM assistance. With an emulated USB device,
> a 101-byte transfer claiming a 1500-byte frame was passed up as a
> 1500-byte packet before this change and is dropped after it, and
> frames claiming 0, 4 and 13 bytes were passed up and are now dropped
> and counted in rx_length_errors. The extra bytes happened to be zero
> in the first test, so disclosure of actual kernel data was not
> demonstrated.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Wei Jie Law <law.wei.jie@gt.tech.gov.sg>
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-10-26 16:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 2:03 [PATCH net v2 0/2] net: usb: pegasus: fix receive length handling Wei Jie Law
2026-10-21 2:03 ` [PATCH net v2 1/2] net: usb: pegasus: do not advance rx_skb->data on dropped frames Wei Jie Law
2026-10-21 2:08 ` sashiko-bot
2026-10-26 16:31 ` Simon Horman
2026-10-21 2:03 ` [PATCH net v2 2/2] net: usb: pegasus: check rx pkt_len against the received length Wei Jie Law
2026-10-21 2:08 ` sashiko-bot
2026-10-26 16:31 ` Simon Horman [this message]
2026-10-26 23:20 ` [PATCH net v2 0/2] net: usb: pegasus: fix receive length handling patchwork-bot+netdevbpf
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=20261026163151.GC257209@horms.kernel.org \
--to=horms@kernel.org \
--cc=98lawweijie@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=kuba@kernel.org \
--cc=law.wei.jie@gt.tech.gov.sg \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petkan@nucleusys.com \
--cc=stable@vger.kernel.org \
/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.