The driver did not handle failure of `netdev_alloc_skb_ip_align()`.
If the allocation failed, dereferencing `skb->protocol` could lead to a
NULL pointer dereference.

This patch adds proper error handling by falling back to the `else` clause
when the allocation fails.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-on: D-Link DGE-550T Rev-A3
Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com>
---
 drivers/net/ethernet/dlink/dl2k.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
index 6bbf6e5584e5..a82e1fd01b92 100644
--- a/drivers/net/ethernet/dlink/dl2k.c
+++ b/drivers/net/ethernet/dlink/dl2k.c
@@ -965,26 +965,31 @@ receive_packet (struct net_device *dev)
 			struct sk_buff *skb;
 
 			/* Small skbuffs for short packets */
-			if (pkt_len > copy_thresh) {
-				dma_unmap_single(&np->pdev->dev,
-						 desc_to_dma(desc),
-						 np->rx_buf_sz,
-						 DMA_FROM_DEVICE);
-				skb_put (skb = np->rx_skbuff[entry], pkt_len);
-				np->rx_skbuff[entry] = NULL;
-			} else if ((skb = netdev_alloc_skb_ip_align(dev, pkt_len))) {
+			if (pkt_len <= copy_thresh) {
+				skb = netdev_alloc_skb_ip_align(dev, pkt_len);
+				if (!skb)
+					goto reuse_skbuff;
+
 				dma_sync_single_for_cpu(&np->pdev->dev,
 							desc_to_dma(desc),
 							np->rx_buf_sz,
 							DMA_FROM_DEVICE);
-				skb_copy_to_linear_data (skb,
+				skb_copy_to_linear_data(skb,
 						  np->rx_skbuff[entry]->data,
 						  pkt_len);
-				skb_put (skb, pkt_len);
+				skb_put(skb, pkt_len);
 				dma_sync_single_for_device(&np->pdev->dev,
 							   desc_to_dma(desc),
 							   np->rx_buf_sz,
 							   DMA_FROM_DEVICE);
+			} else {
+reuse_skbuff:
+				dma_unmap_single(&np->pdev->dev,
+						 desc_to_dma(desc),
+						 np->rx_buf_sz,
+						 DMA_FROM_DEVICE);
+				skb_put(skb = np->rx_skbuff[entry], pkt_len);
+				np->rx_skbuff[entry] = NULL;
 			}
 			skb->protocol = eth_type_trans (skb, dev);
 #if 0
-- 
2.51.0

> -				skb_copy_to_linear_data (skb,
> +				skb_copy_to_linear_data(skb,
>  						  np->rx_skbuff[entry]->data,
>  						  pkt_len);
> -				skb_put (skb, pkt_len);
> +				skb_put(skb, pkt_len);

Please don't include white space changes with other changes. It makes
the patch harder to review.

    Andrew

---
pw-bot: cr

On Sat Sep 13, 2025 at 5:39 AM KST, Andrew Lunn wrote:
>> -				skb_copy_to_linear_data (skb,
>> +				skb_copy_to_linear_data(skb,
>>  						  np->rx_skbuff[entry]->data,
>>  						  pkt_len);
>> -				skb_put (skb, pkt_len);
>> +				skb_put(skb, pkt_len);
>
> Please don't include white space changes with other changes. It makes
> the patch harder to review.
>
>     Andrew
Thank you for reviewing!

As you mentioned, it indeed becomes harder to see what the real changes
are. I have a few questions related to that:

1. If I remove the whitespace between the funciton name and the
parenthesis, `checkpatch.pl` will warn about it. Of course, I understand
that we don't need to follow such rules in a mindessly robotic way.

2. However, I also read in the netdev FAQ that cleanup-only patches are
discouraged. So I thought it would be better to include the cleanup
together with the patch. But I see your point, and I'll be more careful
not to send patches that cause such confusion in the future.

3. This is more of a personal curiosity: in that case, what would be the
proper way to handle cleanup patches?

	Yeounsu Moon

On Sun, Sep 14, 2025 at 05:51:54PM +0900, Yeounsu Moon wrote:
> On Sat Sep 13, 2025 at 5:39 AM KST, Andrew Lunn wrote:
> >> -				skb_copy_to_linear_data (skb,
> >> +				skb_copy_to_linear_data(skb,
> >>  						  np->rx_skbuff[entry]->data,
> >>  						  pkt_len);
> >> -				skb_put (skb, pkt_len);
> >> +				skb_put(skb, pkt_len);
> >
> > Please don't include white space changes with other changes. It makes
> > the patch harder to review.
> >
> >     Andrew
> Thank you for reviewing!
> 
> As you mentioned, it indeed becomes harder to see what the real changes
> are. I have a few questions related to that:
> 
> 1. If I remove the whitespace between the funciton name and the
> parenthesis, `checkpatch.pl` will warn about it. Of course, I understand
> that we don't need to follow such rules in a mindessly robotic way.
> 
> 2. However, I also read in the netdev FAQ that cleanup-only patches are
> discouraged. So I thought it would be better to include the cleanup
> together with the patch. But I see your point, and I'll be more careful
> not to send patches that cause such confusion in the future.
> 
> 3. This is more of a personal curiosity: in that case, what would be the
> proper way to handle cleanup patches?

The problem with cleanup patches is that they are often done by
developers who don't have the hardware, and so don't do any
testing. White space changes like this a low risk, but other cleanup
patches are much more risky. So some cleanup patches end up breaking
stuff. We reviewers know this, and so put in more time looking at such
patches and try to make sure they are correct. But cleanup is
generally lower priority than new code. So to some extent, we prefer
the code is left 'dirty but working'.

In this case, you have the hardware. You are testing your change, so
we are much happier to accept such a cleanup patch as part of a
patchset fixing a real problem.

Please submit two patches in a patchset. The first patch fixes the
whitespace. The second fixes the memory problem with copy break. That
should be checkpatch clean. And mention in the commit message that
this has been tested on hardware.

     Andrew