The driver trusts the RX descriptor length and uses it directly for
dev_alloc_skb(), memcpy_fromio(), and skb_put() without any bounds
checking. If the descriptor gets corrupted or otherwise contains an
invalid value, this can lead to an excessive allocation or reading
past the per-buffer limit programmed by the driver.

Validate 'len' read from the descriptor and drop the frame if it is
zero or greater than HDLC_MAX_MRU. The driver programs BFLL to
HDLC_MAX_MRU for RX buffers, so this is the correct upper bound.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/net/wan/hd64572.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wan/hd64572.c b/drivers/net/wan/hd64572.c
index 534369ffe5de..6327204e3c02 100644
--- a/drivers/net/wan/hd64572.c
+++ b/drivers/net/wan/hd64572.c
@@ -199,6 +199,12 @@ static inline void sca_rx(card_t *card, port_t *port, pkt_desc __iomem *desc,
 	u32 buff;
 
 	len = readw(&desc->len);
+
+	if (unlikely(!len || len > HDLC_MAX_MRU)) {
+		dev->stats.rx_length_errors++;
+		return;
+	}
+
 	skb = dev_alloc_skb(len);
 	if (!skb) {
 		dev->stats.rx_dropped++;
-- 
2.43.0

On 9/26/25 12:49 PM, Guangshuo Li wrote:
> The driver trusts the RX descriptor length and uses it directly for
> dev_alloc_skb(), memcpy_fromio(), and skb_put() without any bounds
> checking. If the descriptor gets corrupted or otherwise contains an
> invalid value, 

Why/how? Is the H/W known to corrupt the descriptors? If so please point
that out in the commit message.
Otherwise, if this is intended to protect vs generic memory corruption
inside the kernel caused by S/W bug, please look for such corruption
root cause instead.

Thanks,

Paolo