linux-kernel - RE: [PATCH net] net: fec: Coverity issue: Dereference null return value

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DB9PR04MB8106CF1A1A6317D30A15583F88E59@DB9PR04MB8106.eurprd04.prod.outlook.com>
Date:   Mon, 19 Dec 2022 02:21:14 +0000
From:   Wei Fang <wei.fang@....com>
To:     Alexander H Duyck <alexander.duyck@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        Clark Wang <xiaoning.wang@....com>,
        Shenwei Wang <shenwei.wang@....com>,
        dl-linux-imx <linux-imx@....com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net] net: fec: Coverity issue: Dereference null return
 value


> -----Original Message-----
> From: Alexander H Duyck <alexander.duyck@...il.com>
> Sent: 2022年12月16日 23:34
> To: Wei Fang <wei.fang@....com>; davem@...emloft.net;
> edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com; Clark Wang
> <xiaoning.wang@....com>; Shenwei Wang <shenwei.wang@....com>;
> dl-linux-imx <linux-imx@....com>
> Cc: netdev@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH net] net: fec: Coverity issue: Dereference null return value
> 
> On Thu, 2022-12-15 at 17:11 +0800, wei.fang@....com wrote:
> > From: Wei Fang <wei.fang@....com>
> >
> > The build_skb might return a null pointer but there is no check on the
> > return value in the fec_enet_rx_queue(). So a null pointer dereference
> > might occur. To avoid this, we check the return value of build_skb. If
> > the return value is a null pointer, the driver will recycle the page
> > and update the statistic of ndev. Then jump to rx_processing_done to
> > clear the status flags of the BD so that the hardware can recycle the BD.
> >
> > Signed-off-by: Wei Fang <wei.fang@....com>
> > Reviewed-by: Shenwei Wang <Shenwei.wang@....com>
> > ---
> >  drivers/net/ethernet/freescale/fec_main.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/freescale/fec_main.c
> > b/drivers/net/ethernet/freescale/fec_main.c
> > index 5528b0af82ae..c78aaa780983 100644
> > --- a/drivers/net/ethernet/freescale/fec_main.c
> > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > @@ -1674,6 +1674,16 @@ fec_enet_rx_queue(struct net_device *ndev, int
> budget, u16 queue_id)
> >  		 * bridging applications.
> >  		 */
> >  		skb = build_skb(page_address(page), PAGE_SIZE);
> > +		if (unlikely(!skb)) {
> > +			page_pool_recycle_direct(rxq->page_pool, page);
> > +			ndev->stats.rx_packets--;
> > +			ndev->stats.rx_bytes -= pkt_len;
> > +			ndev->stats.rx_dropped++;
> 
> I'm not sure you really need to bother with rewinding the rx_packets and
> rx_bytes counters. I know that the rx_dropped statistic will get incremented in
> the network stack in the event of a packet failing to enqueue to the backlog, so
> it might be better to just leave the rx_packets counter as is and assume the
> actual packet count is rx_packets - rx_dropped.
> 
According to your advice, I looked up the Linux document, actually as you said,
the rx_packets should include packets which host had to drop at various stages
of processing (even in the driver). Thanks for your review, I‘ll amend this in the
next version.

> > +
> > +			netdev_err(ndev, "build_skb failed!\n");
> 
> Instead of netdev_err you may want to consider netdev_err_once for this.
> Generally speaking when we start seeing memory allocation error issues they
> can get very noisy very quickly as you are likely to fail the allocation for every
> packet in a given polling session, and sessions to follow.
> 
Yes, it's better to use netdev_err_once than netdev_err in the situation you describe.
Thanks again!

> > +			goto rx_processing_done;
> > +		}
> > +
> >  		skb_reserve(skb, data_start);
> >  		skb_put(skb, pkt_len - sub_len);
> >  		skb_mark_for_recycle(skb);