linux-kernel - Re: [PATCH v1] iio: adc: ad7192: store indio

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]

Message-ID: <20230612124548.00007778@Huawei.com>
Date:   Mon, 12 Jun 2023 12:45:48 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     <andy.shevchenko@...il.com>
CC:     Markus Burri <markus.burri@...com>, <linux-kernel@...r.kernel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Michael Hennerich <Michael.Hennerich@...log.com>,
        Alexandru Tachici <alexandru.tachici@...log.com>,
        Jonathan Cameron <jic23@...nel.org>,
        <linux-iio@...r.kernel.org>
Subject: Re: [PATCH v1] iio: adc: ad7192: store indio_dev into spi driver
 data

On Mon, 12 Jun 2023 13:15:44 +0300
<andy.shevchenko@...il.com> wrote:

> Mon, Jun 12, 2023 at 10:08:47AM +0200, Markus Burri kirjoitti:
> > After calibration the indio_dev is used to get channel information.
> > Since the pointer is not stored into spi driver data, there is a kernel
> > null pointer dereference.
> > Store the indio_dev into spi driver data to fix this.  
> 
> This definitely deserves the Fixes tag. Can you dig the history to find the
> culprit one?

Good catch, but see

https://lore.kernel.org/all/20230530075311.400686-2-fl.scratchpad@gmail.com/

Which I think is a nicer fix for the same issue.

I sent a pull request for that fix yesterday, but given we are late in the cycle
it might go in during the merge window then get backported to stable kernels
after that.

> 
> > Add error check and slightly extend the debug messages.  
> 
> I'm not sure this will belong to the same change, so I would split this out to
> a separate one.

Definitely.  Multiple issues so multiple patches.

Thanks,

Jonathan

>