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

Message-ID:
 <TYUPR06MB621753BFCD4F56F189B9E914D2B7A@TYUPR06MB6217.apcprd06.prod.outlook.com>
Date: Sun, 21 Dec 2025 05:48:01 +0000
From: 胡连勤 <hulianqin@...o.com>
To: Michal Pecio <michal.pecio@...il.com>
CC: Mathias Nyman <mathias.nyman@...ux.intel.com>, Mathias Nyman
	<mathias.nyman@...el.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	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 Fri, 19 Dec 2025 15:53:08 +0000, 胡连勤 wrote:
> > [ 4021.987665][  T332] Call trace:
> > [ 4021.987668][  T332]  dma_pool_alloc+0x3c/0x248 [ 4021.987676][
> > T332]  xhci_segment_alloc+0x9c/0x184 [ 4021.987682][  T332]
> > xhci_alloc_segments_for_ring+0xcc/0x1cc
> > [ 4021.987688][  T332]  xhci_ring_alloc+0xc4/0x1a8 [ 4021.987693][
> > T332]  xhci_endpoint_init+0x36c/0x4ac [ 4021.987698][  T332]
> > xhci_add_endpoint+0x18c/0x2a4 [ 4021.987702][  T332]
> > usb_hcd_alloc_bandwidth+0x384/0x3e4
> > [ 4021.987711][  T332]  usb_set_interface+0x144/0x510 [ 4021.987716][
> > T332]  usb_reset_and_verify_device+0x248/0x5fc
> > [ 4021.987723][  T332]  usb_port_resume+0x580/0x700 [ 4021.987730][
> > T332]  usb_generic_driver_resume+0x24/0x5c
> > [ 4021.987735][  T332]  usb_resume_both+0x104/0x32c [ 4021.987740][
> > T332]  usb_runtime_resume+0x18/0x28 [ 4021.987746][  T332]
> > __rpm_callback+0x94/0x3d4 [ 4021.987754][  T332]
> > rpm_resume+0x3f8/0x5fc [ 4021.987762][  T332]  rpm_resume+0x1fc/0x5fc
> > [ 4021.987769][  T332]  __pm_runtime_resume+0x4c/0x90 [ 4021.987777][
> > T332]  usb_autopm_get_interface+0x20/0x4c
> > [ 4021.987783][  T332]  snd_usb_autoresume+0x68/0x124 [ 4021.987792][
> > T332]  suspend_resume_store+0x2a0/0x2b4 [dwc3_msm
> > a4b7997a2e35cfe1a4a429762003b34dd4e85076]
> 
> This looks like some out of tree driver tries to resume a sound device, and
> apparently it's doing it while c isn't ready, perhaps during the
> power_lost branch in xhci_resume() after full system suspend.

Yes, the logic in the ko part wants to wake up the connected audio device.
Is there a way to determine if xhci_hcd is ready before waking it up?


> I suppose dynamic debug could show better what's going on:
> echo 'module usbcore +p' >/proc/dynamic_debug/control echo 'module
> xhci_hcd +p' >/proc/dynamic_debug/control
>
I enabled dynamic debugging and tried to reproduce the problem again.

> If my guess is right then USB core is failing to prevent device resume during
> HC resume, but IDK whether it's supposed to prevent that or if the out of
> tree driver simply shouldn't be trying such things.
> 
When the connected digital headphones are in sleep mode, 
if there is audio data (notification tone) that needs to be played, 
the audio device needs to be woken up, but an error occurs during the wake-up process.

Thanks