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: <2025122250-commend-bondless-c7e1@gregkh>
Date: Mon, 22 Dec 2025 15:00:15 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: 胡连勤 <hulianqin@...o.com>
Cc: Michal Pecio <michal.pecio@...il.com>, 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 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