drivers/net/ethernet/dlink/dl2k.c | 2 ++ 1 file changed, 2 insertions(+)
If `np->rx_skbuff[entry]` was not allocated before
reuse, `receive_packet()` will cause null dereference.
This patch fixes the issue by breaking out of the loop when
`np->rx_skbuff[entry]` is `NULL`.
Found by inspection.
Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-on: D-Link DGE-550T Rev-A3
---
drivers/net/ethernet/dlink/dl2k.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
index 1996d2e4e3e2..aa3840454fcb 100644
--- a/drivers/net/ethernet/dlink/dl2k.c
+++ b/drivers/net/ethernet/dlink/dl2k.c
@@ -969,6 +969,8 @@ receive_packet (struct net_device *dev)
if (pkt_len <= copy_thresh)
skb = netdev_alloc_skb_ip_align(dev, pkt_len);
if (!skb) {
+ if (!np->rx_skbuff[entry])
+ break;
dma_unmap_single(&np->pdev->dev,
desc_to_dma(desc),
np->rx_buf_sz,
--
2.51.0
On Fri, Oct 10, 2025 at 04:02:22AM +0900, Yeounsu Moon wrote:
> If `np->rx_skbuff[entry]` was not allocated before
> reuse, `receive_packet()` will cause null dereference.
>
> This patch fixes the issue by breaking out of the loop when
> `np->rx_skbuff[entry]` is `NULL`.
I see that if np->rx_skbuff[entry] there will be a dereference.
But I'm less clear on how this situation can occur.
So I think it would be worth adding some explanation of that
to the commit message.
Also, I do see that break will result in np->rx_skbuff[entry],
and other empty entries in that array, being refilled.
This is due to the refill loop that towards the end of receive_packet().
But perhaps it is worth mentioning that in the commit message too?
>
> Found by inspection.
Thanks, that is clear.
>
> Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Tested-on: D-Link DGE-550T Rev-A3
...
On Fri Oct 10, 2025 at 4:18 PM KST, Simon Horman wrote: > On Fri, Oct 10, 2025 at 04:02:22AM +0900, Yeounsu Moon wrote: >> If `np->rx_skbuff[entry]` was not allocated before >> reuse, `receive_packet()` will cause null dereference. >> >> This patch fixes the issue by breaking out of the loop when >> `np->rx_skbuff[entry]` is `NULL`. > > I see that if np->rx_skbuff[entry] there will be a dereference. > But I'm less clear on how this situation can occur. When it failed to reallocate `skb`, and then a lot of packets come in at that time, `skb_put()` in `receive_packet()` will cause a null dereference and the kernel will panic. > So I think it would be worth adding some explanation of that > to the commit message. Sorry, I'll make sure to describe the scenario more clearly in the commit message next time. > > Also, I do see that break will result in np->rx_skbuff[entry], > and other empty entries in that array, being refilled. > This is due to the refill loop that towards the end of receive_packet(). Exactly, that is correct. > But perhaps it is worth mentioning that in the commit message too? You are right. I should mention the effect of the break in the commit message as well. Sorry for making you point it out twice.
© 2016 - 2025 Red Hat, Inc.