linux-kernel - 答复: [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:
 <TYUPR06MB6217CB438F21763401A93E6ED2B4A@TYUPR06MB6217.apcprd06.prod.outlook.com>
Date: Mon, 22 Dec 2025 12:21:09 +0000
From: 胡连勤 <hulianqin@...o.com>
To: Michal Pecio <michal.pecio@...il.com>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>
CC: 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:
 答复: [PATCH] usb: xhci: check Null pointer in segment alloc

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.

Thanks