[RFC] spi: handling a stuck queue worker during controller unregister

[RFC] spi: handling a stuck queue worker during controller unregister

[zhang san]

Hello,

We would appreciate guidance on the cleanup policy when the SPI queue
worker does not stop during controller unregister.

If spi_stop_queue() times out, spi_destroy_queue() may return without
destroying the worker. Our reading of the subsequent
spi_unregister_controller() cleanup path suggests that the controller
and child spi_device objects can be released while a stuck
__spi_pump_messages() operation still accesses them.

Using a synthetic SPI controller whose transfer_one() stalls beyond
the queue-stop timeout, we reproduced 80 KASAN use-after-free reports
on Linux v7.4-rc1 (6628e7d4c6b2). We explored three approaches:

A. Keep an additional reference to the controller while allowing
normal cleanup. This left 16 KASAN reports, involving released child
spi_device state.
B. Preserve the controller and child-device tree on queue teardown
failure. This removed the observed KASAN reports but leaves
substantial resources registered and allocated.
C. Preserve the child devices while continuing some controller-level
unregister operations. This is a design option that has not been
implemented or tested.

We do not propose approach B as a ready-to-merge fix: keeping the
entire registered tree can have unacceptable resource and visibility
consequences. Nor do we have evidence yet that approach C is correct.

Would it be preferable to ensure per-message ownership of the
controller and child device until the pump has definitely terminated,
or is there a safer failure policy already used elsewhere in the SPI
core?

We can provide the prototype diffs, KASAN traces, and test setup
privately. The experiments used a synthetic controller, so hardware
equivalence remains to be established.

If a patch is proposed, please CC me so I can run our KASAN reproducer
against that exact revision and offer a Tested-by tag after a
successful test. If the reported lifetime issue or a concrete design
suggestion informs a later fix, please feel free to reference this
thread in the commit message for attribution and review history.

This analysis originated from an AI-assisted audit and was reviewed
and tested by us.

Best regards
Yaohan Li

Re: [RFC] spi: handling a stuck queue worker during controller unregister

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Wed, Nov 04, 2026 at 12:57:12PM +0800, zhang san wrote:

> Would it be preferable to ensure per-message ownership of the
> controller and child device until the pump has definitely terminated,
> or is there a safer failure policy already used elsewhere in the SPI
> core?

I don't think this is something anyone has really worried about,
removing SPI controllers is very unusual in pactical systems and there's
liable to be plenty of other issues if the hardware vanishes.  Your
suggestion above seems reasonable enough on a first pass, if you post
the patches I can review properly.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC] spi: handling a stuck queue worker during controller unregister

[Yaohan Li]

Hi Mark,

Thanks for offering to review a patch.

I tried a core-side fix for the unregister race, but found that the lifetime
rules need more thought before the patch is ready.

The original problem is that spi_destroy_queue() can time out while the pump
worker is still running. Unregister then continues, potentially releasing the
controller while the worker is still using it.

I experimented with tracking active I/O and waiting for it during removal.
This helped with the original test, but I found a problem with my accounting
for asynchronous transfer_one_message() controllers.

spi_finalize_current_message() signals cur_msg_completion before calling the
message's completion callback. In my experimental patch, the pump can
therefore drop the active I/O count before that callback returns.

I confirmed this with a fake controller and a non-sleeping callback using a
bounded busy-wait to expose the ordering. spi_unregister_controller() returned
while the callback had entered but not exited. The test produced no KASAN
report; it was intended to demonstrate the ordering, not a separate UAF. The
fake peripheral driver deliberately left an asynchronous request outstanding
during remove().

I also found that core-side accounting cannot protect private resources that
a peripheral driver frees while its own asynchronous callbacks can still
access them.

I've stopped work on the experimental patch for now. Before extending it, I'd
appreciate your guidance on two points:

1. Is it the peripheral driver's responsibility to stop new requests and
   drain outstanding asynchronous callbacks before releasing private
   resources in remove(), including requests submitted during removal?
2. If a controller cannot terminate an active transfer, should its driver
   ensure that the transfer completes before unregister returns? Given that
   spi_unregister_controller() returns void, would the core need a different
   contract to handle an unabortable transfer safely?

I can provide the test module, logs and experimental diff if useful.

Thanks,
Yaohan