linux-kernel - Re: [PATCH 3/8] usb: typec: intel_pmc

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]

Message-ID: <CANFp7mXwOXhkOSCwCME_ZbzvNP20OVZYX5sE-7+WtC5buSxTrw@mail.gmail.com>
Date: Wed, 25 Sep 2024 10:29:45 -0700
From: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: heikki.krogerus@...ux.intel.com, tzungbi@...nel.org, jthies@...gle.com, 
	pmalani@...omium.org, akuchynski@...gle.com, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org, 
	linux-usb@...r.kernel.org
Subject: Re: [PATCH 3/8] usb: typec: intel_pmc_mux: Null check before use

On Wed, Sep 25, 2024 at 9:54 AM Dmitry Baryshkov
<dmitry.baryshkov@...aro.org> wrote:
>
> On Wed, Sep 25, 2024 at 09:25:04AM GMT, Abhishek Pandit-Subedi wrote:
> > Make sure the data pointer in typec_mux_state is not null before
> > accessing it.
> >
> > Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
>
> Is the a fix for an actual issue or just good-to-have thing? In the
> former case it lacks a description of how the issue can be triggered and
> a Fixes tag.

This fixes a segfault that occurs when the new Thunderbolt driver is
used because it calls `typec_altmode_notify` with null data. I'm not
sure if that needs a `Fixes` since what's currently running upstream
doesn't actually trigger this error.

I'll update the description with why this is needed. i.e.
---
Make sure the data pointer in typec_mux_state is not null before
accessing it. The new Thunderbolt driver calls typec_altmode_notify
with a NULL pointer for data which can cause this mux configuration
to crash.

>
> > ---
> >
> >  drivers/usb/typec/mux/intel_pmc_mux.c | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c
> > index 56989a0d0f43..4283fead9a69 100644
> > --- a/drivers/usb/typec/mux/intel_pmc_mux.c
> > +++ b/drivers/usb/typec/mux/intel_pmc_mux.c
> > @@ -331,14 +331,19 @@ static int
> >  pmc_usb_mux_tbt(struct pmc_usb_port *port, struct typec_mux_state *state)
> >  {
> >       struct typec_thunderbolt_data *data = state->data;
> > -     u8 cable_rounded = TBT_CABLE_ROUNDED_SUPPORT(data->cable_mode);
> > -     u8 cable_speed = TBT_CABLE_SPEED(data->cable_mode);
> > +     u8 cable_rounded, cable_speed;
> >       struct altmode_req req = { };
> >
> > +     if (!data)
> > +             return 0;
> > +
> >       if (IOM_PORT_ACTIVITY_IS(port->iom_status, TBT) ||
> >           IOM_PORT_ACTIVITY_IS(port->iom_status, ALT_MODE_TBT_USB))
> >               return 0;
> >
> > +     cable_rounded = TBT_CABLE_ROUNDED_SUPPORT(data->cable_mode);
> > +     cable_speed = TBT_CABLE_SPEED(data->cable_mode);
> > +
> >       req.usage = PMC_USB_ALT_MODE;
> >       req.usage |= port->usb3_port << PMC_USB_MSG_USB3_PORT_SHIFT;
> >       req.mode_type = PMC_USB_MODE_TYPE_TBT << PMC_USB_MODE_TYPE_SHIFT;
> > --
> > 2.46.0.792.g87dc391469-goog
> >
>
> --
> With best wishes
> Dmitry