From: Michal Pecio <michal.pecio@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Lee Jones" <lee@kernel.org>, 胡连勤 <hulianqin@vivo.com>,
"Mathias Nyman" <mathias.nyman@linux.intel.com>,
"Mathias Nyman" <mathias.nyman@intel.com>,
"Sarah Sharp" <sarah.a.sharp@linux.intel.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: xhci: check Null pointer in segment alloc
Date: Mon, 22 Dec 2025 08:55:43 +0100 [thread overview]
Message-ID: <20251222085543.4d7430d5.michal.pecio@gmail.com> (raw)
In-Reply-To: <2025122253-stopper-tweed-6e68@gregkh>
On Mon, 22 Dec 2025 08:13:21 +0100, Greg Kroah-Hartman wrote:
> > An API that insists on its users exercising care, knowledge and
> > cognisance sounds fragile and vulnerable.
>
> Fragile yes, vulnerable no. Let's fix the fragility then, but as has
> been pointed out in this thread, we don't know the root cause, and I
> don't even think this "fix" would do the right thing anyway.
The patch looks wrong. I suspect this happens when add_endpoint() is
called concurrently with resume(), which makes little sense. And it
means the same code can probably call add_endpoint() before resume(),
which makes no sense either. We can't do that with suspended HW.
Chances are that this crash isn't even the only thing that could go
wrong when such calls are attempted. For one, xhci_resume() drops
the spinlock after reporting usb_root_hub_lost_power(), so your guess
elsewhere was correct - this code isn't even locked properly.
It seems no operations on USB devices during resume() are expected.
Regards,
Michal
next prev parent reply other threads:[~2025-12-22 7:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 7:18 [PATCH] usb: xhci: check Null pointer in segment alloc 胡连勤
2025-12-19 12:48 ` Mathias Nyman
2025-12-19 15:53 ` 答复: " 胡连勤
2025-12-20 8:08 ` Greg Kroah-Hartman
2025-12-20 11:34 ` 答复: " 胡连勤
2025-12-20 13:15 ` Michal Pecio
2025-12-21 5:48 ` 答复: " 胡连勤
2025-12-22 6:42 ` Lee Jones
2025-12-22 7:13 ` Greg Kroah-Hartman
2025-12-22 7:55 ` Michal Pecio [this message]
2025-12-22 12:21 ` 答复: " 胡连勤
2025-12-22 13:34 ` Alan Stern
2025-12-22 16:49 ` Michal Pecio
2025-12-22 17:03 ` Alan Stern
2025-12-22 21:03 ` Michal Pecio
2025-12-23 3:24 ` Alan Stern
2025-12-23 10:06 ` Michal Pecio
2025-12-23 18:37 ` Alan Stern
2025-12-23 19:43 ` Michal Pecio
2025-12-22 14:00 ` 答复: " Greg Kroah-Hartman
2025-12-21 16:22 ` Greg Kroah-Hartman
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=20251222085543.4d7430d5.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hulianqin@vivo.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mathias.nyman@linux.intel.com \
--cc=sarah.a.sharp@linux.intel.com \
/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