linux-kernel - Re: [PATCH v1] usb: typec: bus: verify partner exists in 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: <CALzBnUGYZXgocCmycqgf6FyCA9qmVYYj9vuVkeXFoQy=E1GiwA@mail.gmail.com>
Date:   Thu, 27 Jul 2023 11:16:05 -0700
From:   RD Babiera <rdbabiera@...gle.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     heikki.krogerus@...ux.intel.com, gregkh@...uxfoundation.org,
        badhri@...gle.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v1] usb: typec: bus: verify partner exists in typec_altmode_attention

On Tue, Jul 25, 2023 at 7:27 PM Guenter Roeck <linux@...ck-us.net> wrote:
> Is this theory or actually observed ?

This is actually observed.

> This dereferences partner
>
> > +
> > +     if (!partner || !pdev)
>
> ... and then checks if partner is NULL.
>
> On top of that, pdev is not NULL even if partner is NULL because
> adev is not the first element of struct altmode.
>
> In summary, this code and the check as implemented does not make
> sense. Maybe partner can be NULL, but pdev will never be NULL.

After looking at it more carefully, I agree on the pdev assignment and check
being odd. I'll follow how typec_altmode_vdm handles the NULL partner case
and remove the NULL check on pdev.

> > +             return -ENODEV;
> >
> >       if (pdev->ops && pdev->ops->attention)
> >               pdev->ops->attention(pdev, vdo);
> > +     else
> > +             return -EOPNOTSUPP;
> > +
>
> So far this was explicitly permitted. Now it will log an error each time it is
> observed. I do not see the point of this log message; obviously it was
> not intended to be considered an error, and I do not understand why it should
> suddenly be one that is worth clogging the log.

My rationale for logging anything is that it will make it easier to
identify port
partners that send Attention messages regardless of whether or not the
port registers the partner Alt Mode. You're right that this is not an error, so
I will treat this case as a successful return moving forward. Then the only
log generated will be for a port partner that sends Attention messages to a
port that hasn't registered an altmode for it.

Thanks for the feedback,
RD