netdev - RE: [PATCH net] dpaa2-eth: Fix possible access beyond end of array

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: <AM0PR04MB499443974108AE8074EAA4AF945E0@AM0PR04MB4994.eurprd04.prod.outlook.com>
Date:   Mon, 25 Mar 2019 09:42:22 +0000
From:   Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Ioana Ciornei <ioana.ciornei@....com>
Subject: RE: [PATCH net] dpaa2-eth: Fix possible access beyond end of array

> -----Original Message-----
> From: Jesper Dangaard Brouer <brouer@...hat.com>
> Sent: Sunday, March 24, 2019 8:29 PM
> To: Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>
> Cc: netdev@...r.kernel.org; davem@...emloft.net; Ioana Ciornei
> <ioana.ciornei@....com>; brouer@...hat.com
> Subject: Re: [PATCH net] dpaa2-eth: Fix possible access beyond end of array
> 
> On Wed, 20 Mar 2019 14:11:04 +0000
> Ioana Ciocoi Radulescu <ruxandra.radulescu@....com> wrote:
> 
> > Make sure we don't try to enqueue XDP_REDIRECT frames to an
> > inexistent FQ.
> >
> > While it is guaranteed not to have more than one queue per core,
> > having fewer queues than CPUs on an interface is a valid
> > configuration.
> >
> > Fixes: d678be1dc1ec ("dpaa2-eth: add XDP_REDIRECT support")
> > Reported-by: Jesper Dangaard Brouer <brouer@...hat.com>
> > Signed-off-by: Ioana Radulescu <ruxandra.radulescu@....com>
> > ---
> >  drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> > index 2ba49e9..1a68052 100644
> > --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> > +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> > @@ -1817,7 +1817,7 @@ static int dpaa2_eth_xdp_xmit_frame(struct
> net_device *net_dev,
> >  	dpaa2_fd_set_format(&fd, dpaa2_fd_single);
> >  	dpaa2_fd_set_ctrl(&fd, FD_CTRL_PTA);
> >
> > -	fq = &priv->fq[smp_processor_id()];
> > +	fq = &priv->fq[smp_processor_id() % dpaa2_eth_queue_count(priv)];
> >  	for (i = 0; i < DPAA2_ETH_ENQUEUE_RETRIES; i++) {
> >  		err = priv->enqueue(priv, fq, &fd, 0);
> 
> Are you sure this is correct?
> How do you guard/lock concurrent CPUs from accessing 'fq' ?

We only use 'fq' in the enqueue command to hardware.
Our hardware can handle concurrent enqueue commands, we
might at most get a busy response from it.

Thanks,
Ioana