All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: LI xiao <lixiao0@hdu.edu.cn>
Cc: vkoul@kernel.org, dmaengine@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: dmaengine: ioat: possible use-after-free on probe failure
Date: Mon, 19 Oct 2026 07:18:23 -0700	[thread overview]
Message-ID: <fd4682a7-79f6-484d-809e-504a8fecd575@intel.com> (raw)
In-Reply-To: <AMgApAB7LHAmvchq*LUlC4qv.1.1792418652126.Hmail.252270051@hdu.edu.cn>



On 10/19/26 7:04 AM, LI xiao wrote:
> Hello,
> 
> I found a possible IRQ lifetime race in the Intel I/OAT DMA driver.
> 
> I reviewed the relevant code in Linux v7.3 at commit c03c1a14507dfaf8b856c2608f9ac216021fc222. In drivers/dma/ioat/init.c, ioat_dma_setup_interrupts() registers IRQ handlers using devm_request_irq(). In MSI-X mode, the handler receives an ioatdma_chan pointer, while in MSI/INTx mode, the handler receives an ioatdma_device pointer.
> 
> If initialization fails after the IRQ handlers have been registered, the err_disable_interrupts path disables device-side interrupts and returns. ioat_pci_probe() then frees the channel objects referenced by device->idx[] and the device itself before returning an error. Since managed IRQ cleanup occurs after the probe callback returns, an IRQ handler that is still running could access a freed channel or device object before the corresponding IRQ is released.
> 
> I tested the suspected lifetime ordering using a test-only kernel module in a mainline v7.3 KASAN-enabled QEMU guest. A test kthread retained a pointer to a simulated device object and waited while the cleanup path disabled simulated interrupts and freed the device. After the kthread resumed and accessed the retained pointer, KASAN reported:
> 
> BUG: KASAN: slab-use-after-free in ioat_irq_handler_repro+0x68/0x70 [ioat_probe_race_repro]
> Read of size 8 at addr ff110001025c0388 by task ioat-irq-test/77
> 
> This is a controlled simulation of the lifetime ordering, not a reproduction through the actual I/OAT driver or hardware. The reported access occurred in the test module's handler, not the driver's actual IRQ handler. QEMU 6.2 does not provide an I/OAT device model, so I could not exercise the real probe-failure path.
> 
> Could you please assess whether this is a bug?
> 
> Best regards,
> LI Xiao

Thank you for the analysis. However given how old this hardware and driver is and there haven't been a field report on this issue, I won't spend the time and analyze this. Patches are welcome if you can reproduce it on hardware. 

      reply	other threads:[~2026-10-19 14:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 14:04 dmaengine: ioat: possible use-after-free on probe failure LI xiao
2026-10-19 14:18 ` Dave Jiang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fd4682a7-79f6-484d-809e-504a8fecd575@intel.com \
    --to=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lixiao0@hdu.edu.cn \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.