linux-kernel - Re: [PATCH] xhci: sideband: Fix race condition in sideband unregister

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 for Android: free password hash cracker in your pocket

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

Message-ID: <51ca2248-5699-4c6d-b037-a57c90ed44ac@linux.intel.com>
Date: Tue, 28 Oct 2025 14:15:29 +0200
From: Mathias Nyman <mathias.nyman@...ux.intel.com>
To: Uttkarsh Aggarwal <uttkarsh.aggarwal@....qualcomm.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Mathias Nyman <mathias.nyman@...el.com>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
 wesley.cheng@....qualcomm.com
Subject: Re: [PATCH] xhci: sideband: Fix race condition in sideband unregister

On 10/28/25 10:00, Uttkarsh Aggarwal wrote:
> A kernel panic was observed due to a race condition between un-registering
> sideband and creating sideband interrupters. The issue occurrs when thread
> T1 runs uaudio_disconnect() and released sb->xhci via sideband_unregister,
> while thread T2 simultaneously accessed the now-NULL sb->xhci in
> xhci_sideband_create_interrupter() resulting in a crash.
> 
> By locking the mutex before modifying sb->xhci, any thread calling
> xhci_sideband_create_interrupter() will either see a valid sb->xhci or wait
> until xhci_sideband_unregister() completes.
> 

Looks like there is a bigger issue with xhci_sideband_unregister() and the mutex.
New endpoints and interrupter can be added to the sideband after
xhci_sideband_unregister() cleared the existing ones, and released the mutex.

We should avoid taking and releasing the mutex several times in unregister,
and make sure we set a flag during first time unregister takes the muxtex, and make
sure no new endpoints and interrupter are added if this flag is set.
Also avoid creating unnecessary locking dependencies between mutex and xhci spinlock.

the xhci->lock looks correct

Maybe we can use sb->vdev as a flag, I'll look into this.

Thanks
Mathias