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] [day] [month] [year] [list]

Date:   Mon, 25 Mar 2019 12:25:57 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <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 Mon, 25 Mar 2019 09:42:22 +0000
Ioana Ciocoi Radulescu <ruxandra.radulescu@....com> wrote:

> > -----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.

Great, then this should be okay :-)

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer