linux-kernel - Re: [PATCH 2/3] usb: typec: ucsi: Move unregister out of atomic section

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: <ZsN2qR3tuXylb2qK@hu-bjorande-lv.qualcomm.com>
Date: Mon, 19 Aug 2024 09:45:29 -0700
From: Bjorn Andersson <quic_bjorande@...cinc.com>
To: Johan Hovold <johan@...nel.org>
CC: Sebastian Reichel <sre@...nel.org>,
        Bjorn Andersson
	<andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        "Heikki
 Krogerus" <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        Chris Lew <quic_clew@...cinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Stephen Boyd
	<swboyd@...omium.org>,
        Amit Pundir <amit.pundir@...aro.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-usb@...r.kernel.org>, <stable@...r.kernel.org>
Subject: Re: [PATCH 2/3] usb: typec: ucsi: Move unregister out of atomic
 section

On Mon, Aug 19, 2024 at 05:06:58PM +0200, Johan Hovold wrote:
> On Sun, Aug 18, 2024 at 04:17:38PM -0700, Bjorn Andersson wrote:
> > Commit 'caa855189104 ("soc: qcom: pmic_glink: Fix race during
> > initialization")' 
> 
> This commit does not exist, but I think you really meant to refer to
> 
> 	9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")
> 
> and possibly also
> 
> 	635ce0db8956 ("soc: qcom: pmic_glink: don't traverse clients list without a lock")
> 
> here.
> 

Yeah, I copy-pasted the wrong SHA1. Prior to commit 9329933699b3 ("soc:
qcom: pmic_glink: Make client-lock non-sleeping") the PDR notification
happened from a worker with only mutexes held.

> > moved the pmic_glink client list under a spinlock, as
> > it is accessed by the rpmsg/glink callback, which in turn is invoked
> > from IRQ context.
> > 
> > This means that ucsi_unregister() is now called from IRQ context, which
> > isn't feasible as it's expecting a sleepable context.
> 
> But this is not correct as you say above that the callback has always
> been made in IRQ context. Then this bug has been there since the
> introduction of the UCSI driver by commit
> 

No, I'm stating that commit 9329933699b3 ("soc: qcom: pmic_glink: Make
client-lock non-sleeping") was needed because the client list is
traversed under the separate glink callback, which has always been made
in IRQ context.

> 	62b5412b1f4a ("usb: typec: ucsi: add PMIC Glink UCSI driver")
> 
> > An effort is under
> > way to get GLINK to invoke its callbacks in a sleepable context, but
> > until then lets schedule the unregistration.
> > 
> > A side effect of this is that ucsi_unregister() can now happen
> > after the remote processor, and thereby the communication link with it, is
> > gone. pmic_glink_send() is amended with a check to avoid the resulting
> > NULL pointer dereference, but it becomes expecting to see a failing send
> 
> Perhaps you can rephrase this bit ("becomes expecting to see").
> 

Sure.

> > upon shutting down the remote processor (e.g. during a restart following
> > a firmware crash):
> > 
> >   ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5
> > 
> > Fixes: caa855189104 ("soc: qcom: pmic_glink: Fix race during initialization")
> 
> So this should be
> 
> Fixes: 62b5412b1f4a ("usb: typec: ucsi: add PMIC Glink UCSI driver")
> 

I think it should be:

9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")

> > Cc: stable@...r.kernel.org
> > Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
>  
> > diff --git a/drivers/usb/typec/ucsi/ucsi_glink.c b/drivers/usb/typec/ucsi/ucsi_glink.c
> > index ac53a81c2a81..a33056eec83d 100644
> > --- a/drivers/usb/typec/ucsi/ucsi_glink.c
> > +++ b/drivers/usb/typec/ucsi/ucsi_glink.c
> > @@ -68,6 +68,9 @@ struct pmic_glink_ucsi {
> >  
> >  	struct work_struct notify_work;
> >  	struct work_struct register_work;
> > +	spinlock_t state_lock;
> > +	unsigned int pdr_state;
> > +	unsigned int new_pdr_state;
> 
> Should these be int to match the notify callback (and enum
> servreg_service_state)?
> 

Ohh my. I made it unsigned because I made it unsigned in pmic_glink,
when I wrote that. But as you point out, the type passed around is an
enum servreg_service_state and it's mostly handled as a signed int.

That said, pmic_glink actually filters the value space down to UP/DOWN,
so making this "bool pdr_up" (pd_running?) and "bool ucsi_registered"
would make this cleaner...

> >  	u8 read_buf[UCSI_BUF_SIZE];
> >  };
> > @@ -244,8 +247,22 @@ static void pmic_glink_ucsi_notify(struct work_struct *work)
> >  static void pmic_glink_ucsi_register(struct work_struct *work)
> >  {
> >  	struct pmic_glink_ucsi *ucsi = container_of(work, struct pmic_glink_ucsi, register_work);
> > +	unsigned long flags;
> > +	unsigned int new_state;
> 
> Then int here too.
> 

Yes.

> > +
> > +	spin_lock_irqsave(&ucsi->state_lock, flags);
> > +	new_state = ucsi->new_pdr_state;
> > +	spin_unlock_irqrestore(&ucsi->state_lock, flags);
> > +
> > +	if (ucsi->pdr_state != SERVREG_SERVICE_STATE_UP) {
> > +		if (new_state == SERVREG_SERVICE_STATE_UP)
> > +			ucsi_register(ucsi->ucsi);
> > +	} else {
> > +		if (new_state == SERVREG_SERVICE_STATE_DOWN)
> > +			ucsi_unregister(ucsi->ucsi);
> 
> Do you risk a double deregistration (and UAF/double free) here?
> 

I believe we're good.

Thank you,
Bjorn

> > +	}
> >  
> > -	ucsi_register(ucsi->ucsi);
> > +	ucsi->pdr_state = new_state;
> >  }
> 
> Johan