linux-kernel - Re: [PATCH v11 5/8] iio: adc: adi-axi-adc: add support for AXI ADC IP core

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:   Sun, 22 Mar 2020 09:16:36 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "Grozav, Andrei" <Andrei.Grozav@...log.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jic23@...nel.org" <jic23@...nel.org>,
        "Hennerich, Michael" <Michael.Hennerich@...log.com>,
        "Nagy, Laszlo" <Laszlo.Nagy@...log.com>,
        "Csomortani, Istvan" <Istvan.Csomortani@...log.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "Bogdan, Dragos" <Dragos.Bogdan@...log.com>,
        "Costina, Adrian" <Adrian.Costina@...log.com>
Subject: Re: [PATCH v11 5/8] iio: adc: adi-axi-adc: add support for AXI ADC
 IP core

On Sun, Mar 22, 2020 at 12:45:39PM +0200, Andy Shevchenko wrote:
> +Cc Kees (see below about allocation size checks)
> 
> On Sun, Mar 22, 2020 at 11:36 AM Ardelean, Alexandru
> <alexandru.Ardelean@...log.com> wrote:
> > On Sat, 2020-03-21 at 23:38 +0200, Andy Shevchenko wrote:
> > > On Sat, Mar 21, 2020 at 10:55 AM Alexandru Ardelean
> > > <alexandru.ardelean@...log.com> wrote:
> 
> ...
> 
> > > > +static struct adi_axi_adc_conv *adi_axi_adc_conv_register(struct device
> > > > *dev,
> > > > +                                                         int sizeof_priv)
> > > > +{
> > > > +       struct adi_axi_adc_client *cl;
> > > > +       size_t alloc_size;
> > > > +
> > > > +       alloc_size = sizeof(struct adi_axi_adc_client);
> > > > +       if (sizeof_priv) {
> > > > +               alloc_size = ALIGN(alloc_size, IIO_ALIGN);
> > > > +               alloc_size += sizeof_priv;
> > > > +       }
> > > > +       alloc_size += IIO_ALIGN - 1;
> > >
> > > Have you looked at linux/overflow.h?
> >
> > i did now;
> > any hints where i should look closer?
> 
> It seems it lacks of this kind of allocation size checks... Perhaps add one?
> Kees, what do you think?
> 
> > > > +       cl = kzalloc(alloc_size, GFP_KERNEL);
> > > > +       if (!cl)
> > > > +               return ERR_PTR(-ENOMEM);

My head hurts trying to read this! ;) Okay, so the base size is
sizeof(struct adi_axi_adc_client). But if sizeof_priv is non-zero
(this arg should be size_t not int), then we need to make the struct
size ALIGNed? And then what is the "+= IIO_ALIGN - 1" for?

It's not clear to me what the expect alignment/padding is here.

I would probably construct this as:

	sizeof_self = sizeof(struct adi_axi_adc_client);
	if (sizeof_priv)
		sizeof_self = ALIGN(sizeof_self, IIO_ALIGN);
	if (check_add_overflow(sizeof_self, sizeof_priv, &sizeof_alloc))
		return ERR_PTR(-ENOMEM);
	if (check_add_overflow(sizeof_alloc, IIO_ALIGN - 1, &sizeof_alloc))
		return ERR_PTR(-ENOMEM);

But I don't understand the "IIO_ALIGN - 1" part, so I assume this could
be shortened with better use of ALIGN()?

Also, this feels like a weird driver allocation overall:

+	struct adi_axi_adc_conv **ptr, *conv;
+
+	ptr = devres_alloc(devm_adi_axi_adc_conv_release, sizeof(*ptr),
+			   GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	conv = adi_axi_adc_conv_register(dev, sizeof_priv);

devres_alloc() allocates storage for a _single pointer_. :P That's not
useful for resource tracking. Why is devres_alloc() being called here
and not down in adi_axi_adc_conv_register() and just passing the pointer
back up?

-- 
Kees Cook