From: Qasim Ijaz <qasdev00@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, yyyynoom@gmail.com, horms@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: dl2k: fix potential null deref in receive_packet()
Date: Fri, 21 Mar 2025 18:42:32 +0000 [thread overview]
Message-ID: <Z92zGMsCPHCIbx62@qasdev.system> (raw)
In-Reply-To: <CANn89iJ+VtuyB1tRLeNqVzx3ZpxEiusyfAJv855B90P2XcpDag@mail.gmail.com>
On Fri, Mar 21, 2025 at 04:13:04PM +0100, Eric Dumazet wrote:
> On Fri, Mar 21, 2025 at 1:15 PM Qasim Ijaz <qasdev00@gmail.com> wrote:
> >
> > If the pkt_len is less than the copy_thresh the netdev_alloc_skb_ip_align()
> > is called to allocate an skbuff, on failure it can return NULL. Since
> > there is no NULL check a NULL deref can occur when setting
> > skb->protocol.
> >
> > Fix this by introducing a NULL check to handle allocation failure.
> >
> > Fixes: 89d71a66c40d ("net: Use netdev_alloc_skb_ip_align()")
>
> This commit has not changed the behavior in case of memory alloc error.
>
Hi Eric,
Thanks for pointing this out, I referenced this commit because it
added the netdev_alloc_skb_ip_align() call without ensuring the
result of it succeeds or not. Before this change the code used
netdev_alloc_skb(), so I now see that there is no functional
difference since an allocation occurs in both versions.
> > Signed-off-by: Qasim Ijaz <qasdev00@gmail.com>
> > ---
> > drivers/net/ethernet/dlink/dl2k.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
> > index d0ea92607870..22e9432adea0 100644
> > --- a/drivers/net/ethernet/dlink/dl2k.c
> > +++ b/drivers/net/ethernet/dlink/dl2k.c
> > @@ -968,6 +968,11 @@ receive_packet (struct net_device *dev)
> > np->rx_buf_sz,
> > DMA_FROM_DEVICE);
> > }
> > +
> > + if (unlikely(!skb)) {
> > + np->rx_ring[entry].fraginfo = 0;
>
> Not sure how this was tested...
>
> I think this would leak memory.
Could you please elaborate on where you think this may arise so I can
investigate further and try to amend it?
Thanks
Qasim
>
> > + break;
> > + }
> > skb->protocol = eth_type_trans (skb, dev);
> > #if 0
> > /* Checksum done by hw, but csum value unavailable. */
> > --
> > 2.39.5
prev parent reply other threads:[~2025-03-21 18:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 12:13 [PATCH] net: dl2k: fix potential null deref in receive_packet() Qasim Ijaz
2025-03-21 15:13 ` Eric Dumazet
2025-03-21 18:42 ` Qasim Ijaz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z92zGMsCPHCIbx62@qasdev.system \
--to=qasdev00@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yyyynoom@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.