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

[Alan Stern]

On Mon, Dec 22, 2025 at 05:49:34PM +0100, Michal Pecio wrote:
> That's not the situation here. The problematic resume is that of the
> host controller itself, it's the only place I see which is expected to
> destroy the segment pool at runtime (other than stop()) and possibly
> cause the reported NULL derefence.

Well, there are two resumes in question: The problematic resume of the 
xhci-hcd device (which you deduce happened because the segment pool was 
destroyed) and the resume of the sound device (which caused the crash by 
trying to add a new endpoint).

> It is not expected that anyone will add endpoints (and probably do
> anything) while the HC is resuming. No sanity checks for that either,
> the driver just does stupid things. It likely does stupid things too
> if you try to manipulate devices while the HC is suspended.

By the time the sound device's resume routine runs, the HC should be 
fully resumed.  That's why I wrote earlier that it would help to get 
logs showing exactly when all the suspends and resumes take place.

> And it looks like somebody found a way of doing just that, by calling
> snd_usb_autoresume() at inappropriate time for some reason. The export
> was added by Wesley Chang, so I guess it was part of "audio offload".
> IDK if offload uses it correctly. Somebody uses it incorrectly.

There's not supposed to be an inappropriate time for doing an 
autoresume.  But I haven't specifically checked the code in 
snd_usb_autoresume().

> Resuming some USB device wouldn't destroy the segment pool and cause
> this crash. Here, device resume tries to add an endpoint and crashes
> because something else has destroyed the pool.

Exactly.  It would be nice to know just what that something else was.

Alan Stern