[PATCH] net: usb: net1080: fix out-of-bounds access in rx_fixup()

net1080_rx_fixup() reads hdr_len from the USB device and uses it to
strip the header with skb_pull(). It then calculates the trailer
pointer as:

  trailer = (struct nc_trailer *)(skb->data + skb->len - sizeof *trailer);

If hdr_len is close to skb->len (e.g. skb->len - 1), the pull leaves
fewer bytes than sizeof(nc_trailer) = 2, and the pointer arithmetic
underflows, pointing before skb->data. The subsequent read of
trailer->packet_id accesses memory outside the skb buffer.

A malicious USB device can craft a frame with hdr_len >= MIN_HEADER (6)
but large enough to leave insufficient room for the trailer after the
header is stripped.

Add a check that the frame is long enough to contain both the header
and trailer before pulling.

Fixes: 904813cd8a0b3 ("[PATCH] USB: usbnet (4/9) module for net1080 cables")
Cc: stable@vger.kernel.org
Signed-off-by: Aamir Ahmed <redacted>
Assisted-by: Claude (Anthropic)
---
 drivers/net/usb/net1080.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index 19f6e1222d931..64477a4caa07b 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c

@@ -374,6 +374,13 @@ static int net1080_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
 		nc_ensure_sync(dev);
 		// switch (vendor/product ids) { ... }
 	}
+	if (hdr_len + sizeof(*trailer) > skb->len) {
+		dev->net->stats.rx_frame_errors++;
+		netdev_dbg(dev->net, "header too long for frame, %d\n",
+			   hdr_len);
+		nc_ensure_sync(dev);
+		return 0;
+	}
 	skb_pull(skb, hdr_len);
 
 	trailer = (struct nc_trailer *)

-- 
2.43.0

Please drop this patch.

I rechecked the code earlier and there is no out-of-bounds access to
fix here, so the commit message is wrong.

skb_pull() returns NULL without modifying the skb when hdr_len is
larger than skb->len, and when it does pull it leaves skb->data +
skb->len unchanged. Either way

  trailer = (struct nc_trailer *)(skb->data + skb->len - sizeof *trailer);

resolves to the last two bytes of the frame as received, which is in
bounds because of the earlier skb->len < hard_header_len check. The
read of skb->data[packet_len] is likewise already guarded by the
packet_len >= skb->len test above it.

Thank you.

pw-bot: changes-requested