From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] usb: phy: Initialize struct usb_phy list_head
Date: Fri, 21 Nov 2025 17:48:49 +0100 [thread overview]
Message-ID: <2025112111-impotency-unguarded-5e07@gregkh> (raw)
In-Reply-To: <44e00ee1-401d-41e8-b5c7-8070ce6d514e@tecnico.ulisboa.pt>
On Fri, Nov 21, 2025 at 04:39:58PM +0000, Diogo Ivo wrote:
>
>
> On 11/21/25 15:03, Greg Kroah-Hartman wrote:
> > On Fri, Nov 21, 2025 at 02:55:35PM +0000, Diogo Ivo wrote:
> > >
> > >
> > > On 11/21/25 14:09, Greg Kroah-Hartman wrote:
> > > > On Thu, Nov 13, 2025 at 02:59:06PM +0000, Diogo Ivo wrote:
> > > > > When executing usb_add_phy() and usb_add_phy_dev() it is possible that
> > > > > usb_add_extcon() fails (for example with -EPROBE_DEFER), in which case
> > > > > the usb_phy does not get added to phy_list via
> > > > > list_add_tail(&x->head, phy_list).
> > > > >
> > > > > Then, when the driver that tried to add the phy receives the error
> > > > > propagated from usb_add_extcon() and calls into usb_remove_phy() to
> > > > > undo the partial registration there will be an unconditional call to
> > > > > list_del(&x->head) which is notinitialized and leads to a NULL pointer
> > > > > dereference.
> > > > >
> > > > > Fix this by initializing x->head before usb_add_extcon() has a chance to
> > > > > fail.
> > > > >
> > > > > Fixes: 7d21114dc6a2d53 ("usb: phy: Introduce one extcon device into usb phy")
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
> > > > > ---
> > > > > drivers/usb/phy/phy.c | 4 ++++
> > > > > 1 file changed, 4 insertions(+)
> > > > >
> > > > > diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
> > > > > index e1435bc59662..5a9b9353f343 100644
> > > > > --- a/drivers/usb/phy/phy.c
> > > > > +++ b/drivers/usb/phy/phy.c
> > > > > @@ -646,6 +646,8 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
> > > > > return -EINVAL;
> > > > > }
> > > > > + INIT_LIST_HEAD(&x->head);
> > > > > +
> > > > > usb_charger_init(x);
> > > > > ret = usb_add_extcon(x);
> > > > > if (ret)
> > > > > @@ -696,6 +698,8 @@ int usb_add_phy_dev(struct usb_phy *x)
> > > > > return -EINVAL;
> > > > > }
> > > > > + INIT_LIST_HEAD(&x->head);
> > > > > +
> > > > > usb_charger_init(x);
> > > > > ret = usb_add_extcon(x);
> > > > > if (ret)
> > > > >
> > > >
> > > > Shouldn't you be also removing an existing call to INIT_LIST_HEAD()
> > > > somewhere? This is not "moving" the code, it is adding it.
> > >
> > > From my understanding that's exactly the problem, currently there is no
> > > call to INIT_LIST_HEAD() anywhere on these code paths, meaning that if
> > > we do not reach the point of calling list_add_tail() at the end of
> > > usb_add_phy() and usb_phy_add_dev() then x->head will remain uninitialized
> > > and fault when running usb_remove_phy().
> >
> > Then how does this work at all if the list is never initialized?
>
> In this case in drivers/usb/phy/phy.c a static LIST_HEAD(phy_list) is
> declared and then for each new 'struct usb_phy *x' the x->head entry
> will get added to this list by calling list_add_tail(&x->head, &phy_list).
Great, can you document this in the changelog text so that it makes more
sense (and properly quote the fixes: sha1, I think you have too many
digits there...) and resend a v2.
thanks,
greg k-h
next prev parent reply other threads:[~2025-11-21 16:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 14:59 [PATCH] usb: phy: Initialize struct usb_phy list_head Diogo Ivo
2025-11-21 14:09 ` Greg Kroah-Hartman
2025-11-21 14:55 ` Diogo Ivo
2025-11-21 15:03 ` Greg Kroah-Hartman
2025-11-21 16:39 ` Diogo Ivo
2025-11-21 16:48 ` Greg Kroah-Hartman [this message]
2025-11-21 17:03 ` Diogo Ivo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025112111-impotency-unguarded-5e07@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=diogo.ivo@tecnico.ulisboa.pt \
--cc=felipe.balbi@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox