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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <38822950-6d69-4ad6-be28-fb8f328c8ae5@rowland.harvard.edu>
Date: Mon, 22 Dec 2025 12:03:45 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Michal Pecio <michal.pecio@...il.com>
Cc: 胡连勤 <hulianqin@...o.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Lee Jones <lee@...nel.org>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...el.com>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: xhci: check Null pointer in segment alloc

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