CVE-2026-23009

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: sideband: don&amp;#39;t dereference freed ring when removing sideband endpoint<br /> <br /> xhci_sideband_remove_endpoint() incorrecly assumes that the endpoint is<br /> running and has a valid transfer ring.<br /> <br /> Lianqin reported a crash during suspend/wake-up stress testing, and<br /> found the cause to be dereferencing a non-existing transfer ring<br /> &amp;#39;ep-&gt;ring&amp;#39; during xhci_sideband_remove_endpoint().<br /> <br /> The endpoint and its ring may be in unknown state if this function<br /> is called after xHCI was reinitialized in resume (lost power), or if<br /> device is being re-enumerated, disconnected or endpoint already dropped.<br /> <br /> Fix this by both removing unnecessary ring access, and by checking<br /> ep-&gt;ring exists before dereferencing it. Also make sure endpoint is<br /> running before attempting to stop it.<br /> <br /> Remove the xhci_initialize_ring_info() call during sideband endpoint<br /> removal as is it only initializes ring structure enqueue, dequeue and<br /> cycle state values to their starting values without changing actual<br /> hardware enqueue, dequeue and cycle state. Leaving them out of sync<br /> is worse than leaving it as it is. The endpoint will get freed in after<br /> this in most usecases.<br /> <br /> If the (audio) class driver want&amp;#39;s to reuse the endpoint after offload<br /> then it is up to the class driver to ensure endpoint is properly set up.