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++;
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
linux-stable-mirror@lists.linaro.org