linux-kernel - Re: [PATCH] usb: typec: mux: Fix matching with typec_altmode

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: <20210517154433.GU2484@yoga>
Date:   Mon, 17 May 2021 10:44:33 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jun Li <jun.li@....com>, Hans de Goede <hdegoede@...hat.com>,
        USB <linux-usb@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: typec: mux: Fix matching with typec_altmode_desc

On Mon 17 May 10:37 CDT 2021, Andy Shevchenko wrote:

> On Mon, May 17, 2021 at 6:14 PM Bjorn Andersson
> <bjorn.andersson@...aro.org> wrote:
> > On Mon 17 May 04:13 CDT 2021, Andy Shevchenko wrote:
> > > On Sun, May 16, 2021 at 6:47 AM Bjorn Andersson
> > > <bjorn.andersson@...aro.org> wrote:
> > > >
> > > > In typec_mux_match() "nval" is assigned the number of elements in the
> > > > "svid" fwnode property, then the variable is used to store the success
> > > > of the read and finally attempts to loop between 0 and "success" - i.e.
> > > > not at all - and the code returns indicating that no match was found.
> > > >
> > > > Fix this by using a separate variable to track the success of the read,
> > > > to allow the loop to get a change to find a match.
> 
> ...
> 
> > > > -       nval = fwnode_property_read_u16_array(fwnode, "svid", val, nval);
> > > > -       if (nval < 0) {
> > > > +       ret = fwnode_property_read_u16_array(fwnode, "svid", val, nval);
> > > > +       if (ret < 0) {
> > > >                 kfree(val);
> > > > -               return ERR_PTR(nval);
> > > > +               return ERR_PTR(ret);
> > > >         }
> > >
> > > This changes the behaviour of the original code, i.e. nval can be
> > > still positive but less than we got from previous call. Some fwnode
> > > backends in some cases potentially can _successfully_ read less than
> > > asked.
> > >
> > > Perhaps
> > >
> > >   nval = ret;
> > >
> > > or drop the patch.
> > >
> >
> > Per the kerneldoc of fwnode_property_read_u16_array:
> >
> >  * Return: number of values if @val was %NULL,
> >  *         %0 if the property was found (success),
> >
> > @val is not NULL, as we just checked for that, so the function will
> > always return 0 on success.
> >
> > I don't see anything indicating that the number of elements can be
> > different from what fwnode_property_count_u16() returned.
> 
> Okay, I have checked the backends of fwnode and indeed, OF case (from
> where I remember such behaviour) deliberately does
> 
> if (ret >= 0)
>   return 0;
> 
> Otherwise the rest return 0 directly / explicitly.
> 
> The only exception is _read_string_array().
> 

I wasn't aware that the string array behaved difference, and the
kernel-doc gives no hint either. Thanks for pointing it out.

Regards,
Bjorn