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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.