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] [day] [month] [year] [list]

Message-ID: <20251222085543.4d7430d5.michal.pecio@gmail.com>
Date: Mon, 22 Dec 2025 08:55:43 +0100
From: Michal Pecio <michal.pecio@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Lee Jones <lee@...nel.org>, 胡连勤
 <hulianqin@...o.com>, 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, 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.

Regards,
Michal