Re: usb: ohci: double dma_pool_destroy of td_cache when the second pool allocation fails in ohci_mem_init()

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Oct 30, 2026 at 07:39:07PM +0800, 徐晗翔 wrote:
> When the second DMA pool allocation in ohci_mem_init() fails, the
> error branch destroys the first pool (td_cache) but leaves
> ohci->td_cache dangling, and ohci_init() then calls the FULL
> ohci_stop() on the failure path -- whose ohci_mem_cleanup() destroys
> the same pool a second time through freed memory: the second
> dma_pool_destroy() re-does list_del on LIST_POISON'ed links (or
> silently corrupts whatever now owns the reused slab object),
> dereferences pool->dev, walks the freed page list double-freeing the
> coherent DMA pages, and kfrees the pool object again.  I confirmed it
> deterministically on a pristine Linux 7.3 KASAN kernel by injecting
> exactly the allocation failure (kretprobe flipping the second
> dma_pool_create() return to NULL, equivalent to slab fault
> injection): the very next controller probe produced
> "BUG: KASAN: slab-use-after-free in dma_pool_destroy" with the use
> stack dma_pool_destroy <- ohci_stop <- ohci_init <- ohci_pci_reset <-
> usb_add_hcd and the allocation stack kmalloc <- dma_pool_create_node
> <- ohci_init.  The fix is one line (NULL the pointer), and a broader
> cleanup would stop ohci_init()'s failure path from running a full
> ohci_stop() that was designed for started controllers (it also calls
> free_irq() with hcd->irq==0 at this stage, printing "Trying to free
> already-free IRQ 0" on the same path).

Great, please send a patch to fix this.  Creating random kernel modules
to break existing kernel modules is a bit odd of a thing to do :)

thanks,

greg k-h