linux-kernel - Re: [PATCH] spi: Avoid calling spi_slave

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]

Date:   Tue, 1 Oct 2019 13:07:13 +0200
From:   Lukasz Majewski <lukma@...x.de>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Colin Ian King <colin.king@...onical.com>,
        linux-spi <linux-spi@...r.kernel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kbuild test robot <lkp@...el.com>,
        Julia Lawall <julia.lawall@...6.fr>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [PATCH] spi: Avoid calling spi_slave_abort() with kfreed spidev

Hi Geert,

> Hi Lukasz,
> 
> On Tue, Oct 1, 2019 at 11:34 AM Lukasz Majewski <lukma@...x.de> wrote:
> > > On Tue, Oct 1, 2019 at 11:07 AM Lukasz Majewski <lukma@...x.de>
> > > wrote:  
> > > > Call spi_slave_abort() only when the spidev->spi is !NULL and
> > > > the structure hasn't already been kfreed.
> > > >
> > > > Reported-by: kbuild test robot <lkp@...el.com>
> > > > Reported-by: Julia Lawall <julia.lawall@...6.fr>
> > > > Reported-by: Dan Carpenter <dan.carpenter@...cle.com>
> > > > Signed-off-by: Lukasz Majewski <lukma@...x.de>  
> 
> > > > --- a/drivers/spi/spidev.c
> > > > +++ b/drivers/spi/spidev.c
> > > > @@ -600,15 +600,16 @@ static int spidev_open(struct inode
> > > > *inode, struct file *filp) static int spidev_release(struct
> > > > inode *inode, struct file *filp) {
> > > >         struct spidev_data      *spidev;
> > > > +       int dofree;
> > > >
> > > >         mutex_lock(&device_list_lock);
> > > >         spidev = filp->private_data;
> > > >         filp->private_data = NULL;
> > > > +       dofree = 0;
> > > >
> > > >         /* last close? */
> > > >         spidev->users--;
> > > >         if (!spidev->users) {
> > > > -               int             dofree;
> > > >
> > > >                 kfree(spidev->tx_buffer);
> > > >                 spidev->tx_buffer = NULL;
> > > > @@ -628,7 +629,8 @@ static int spidev_release(struct inode
> > > > *inode, struct file *filp) kfree(spidev);
> > > >         }
> > > >  #ifdef CONFIG_SPI_SLAVE
> > > > -       spi_slave_abort(spidev->spi);
> > > > +       if (!dofree)
> > > > +               spi_slave_abort(spidev->spi);  
> > >
> > > Can spidev->spi be NULL, if spidev->users != 0?  
> >
> > No, it shouldn't be.
> >
> > The "dofree" is only set to true (the spidev->spi == NULL condition
> > is checked) if there are no references (spidev->users == 0).
> >
> > The if (!dofree) prevents from calling spi_slave_abort() when
> > spidev->spi == NULL and spidev is kfree'd.  
> 
> If spidev->users != 0, the block checking spidev->spi == NULL is never
> executed, and spi_slave_abort() will be called.

Yes, this is correct. My other patch [1] clears the FIFOs in SPI IP
block and ends (if there are any stalled) DMA transactions.

> 
> I'm wondering if spidev->spi can be NULL if spidev->users is still
> positive.

I think that it cannot.

From my tests [2] - when I do enter spi_slave_abort() function the state
of
spidev->users: 0 dofree: 0 spidev->spi: 0x51337072

So it is possible to call the spidev_release without previously setting
spidev->spi to NULL (which is done in spidev_remove() function).

IMHO the above behavior also seems to be correct, as during distortion
the slave losts synchronization from master.

The spidev_remove() callback is part of spi_device struct and is
called when the device is removed (rmmod spi_fsl_dspi).

From my tests the spidev_release() is NOT called after spidev_remove(),
so the code in former seems to be a dead one.

Or maybe there is an use case which causes calling spidev_release()
after spidev_remove()?

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Note:

[1] - https://lkml.org/lkml/2019/9/24/245
[2] -
https://github.com/lmajewski/tests-spi/blob/master/tests/spi/spi_tests.sh

HW setup:  HW loopback with two /dev/spidevX.Y devices used

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped