Re: 答复: [PATCH] usb: xhci: check Null pointer in segment alloc

From: Greg Kroah-Hartman

Date: Mon Dec 22 2025 - 09:00:19 EST


On Mon, Dec 22, 2025 at 12:21:09PM +0000, 胡连勤 wrote:
> Hi Michal:
>
> > 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.
>
> Currently, after checking the logic of our KO section,
> we found that there might be two places simultaneously calling snd_usb_autoresume to wake up the headset device.

Can you provide a link to the source for your kernel code so that we can
review it as well?

thanks,

greg k-h