Netdev List
 help / color / mirror / Atom feed
From: "Tianchu Chen" <tianchu.chen@linux.dev>
To: "Jakub Kicinski" <kuba@kernel.org>
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
	pabeni@redhat.com, linux-usb@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH] net: usb: cx82310_eth: stop parsing reboot marker as packet
Date: Tue, 30 Jun 2026 10:30:53 +0000	[thread overview]
Message-ID: <e87b8ecf4bbcf87635d144508bf35377dd5397b3@linux.dev> (raw)
In-Reply-To: <20260629174458.6ebf647d@kernel.org>

June 30, 2026 at 8:44 AM, "Jakub Kicinski" <kuba@kernel.org mailto:kuba@kernel.org?to=%22Jakub%20Kicinski%22%20%3Ckuba%40kernel.org%3E > wrote:

> 
> On Thu, 25 Jun 2026 15:32:04 +0000 Tianchu Chen wrote:
> 
> > 
> > From: Tianchu Chen <flynnnchen@tencent.com>
> >  
> >  Discovered by Atuin - Automated Vulnerability Discovery Engine.
> >  
> >  cx82310_rx_fixup() treats an RX length of 0xffff as a device reboot
> >  marker and schedules work to re-enable ethernet mode, but then continues
> >  processing the marker as a normal packet length. This is an out-of-bounds
> >  heap write controlled by the usb device.
> > 
> Where? Can you be more specific in the commit message? At a glance 
> the accesses seem to be bound-checked with skb->len.
> -- 
> pw-bot: cr
>


The "len > skb->len" check bounds the source read, but the overflow is on the
destination buffer.

The buggy path is:

	if (len == 0xffff) {
		netdev_info(dev->net, "router was rebooted, re-enabling ethernet mode");
		schedule_work(&priv->reenable_work);
		/* <- BUG: missing return; 0xffff bypasses the oversized-length reject */
	} else if (len > CX82310_MTU) {
		netdev_err(dev->net, "RX packet too long: %d B\n", len);
		return 0;
	}
	if (len > skb->len) {
		dev->partial_len = skb->len; // skb->len is bounded by the USB transfer size (4K)
		dev->partial_rem = len - skb->len;
		memcpy((void *)dev->partial_data, skb->data,
		       dev->partial_len); /* <- TRIGGER: can copy 4K bytes into 1516-byte partial_data */
...
...
	}

For normal oversized lengths, the len > CX82310_MTU branch rejects
before this copy. But 0xffff is special-cased and falls through. With a
4096-byte RX URB, after the 2-byte length header is pulled, skb->len can
be 4094, while partial_data is allocated as dev->hard_mtu
(CX82310_MTU + 2, 1516 bytes).

So the source read is bounded by skb->len; the destination write is not.

I am happy to send a v2 with this spelled out more clearly in the commit message
if needed.

Best regards,
Tianchu Chen

      reply	other threads:[~2026-06-30 10:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-25 15:32 [PATCH] net: usb: cx82310_eth: stop parsing reboot marker as packet Tianchu Chen
2026-06-30  0:44 ` Jakub Kicinski
2026-06-30 10:30   ` Tianchu Chen [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=e87b8ecf4bbcf87635d144508bf35377dd5397b3@linux.dev \
    --to=tianchu.chen@linux.dev \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --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