Re: [PATCH v5] serial: 8250: fix use-after-free in IRQ chain handling

[Jing Wu <realwujing@gmail.com>]

From: Qiliang Yuan <realwujing@gmail.com>

On Wed, Jun 24, 2026 at 05:31:59AM +0200, Jiri Slaby wrote:
> So what is the reason to switch from guards to manual locking?

Scope-based guards release the lock at the end of the enclosing block,
but the fix requires hash_mutex to be held across request_irq() and
released at different exit points:

  1. IS_ERR(i) -- release hash_mutex and return error.
  2. Already in chain -- release i->lock, release hash_mutex, return 0.
  3. First port, request_irq() fails -- cleanup under hash_mutex, then
     release it and return error.
  4. First port, request_irq() succeeds -- release hash_mutex, return 0.

These paths span different nesting levels and early returns, so scope
guards cannot express the required lock lifecycle.  The same applies to
i->lock: it must be dropped before calling request_irq() (cannot hold a
spinlock while sleeping), but hash_mutex must remain held across the
call, which also breaks the guard model.

Thanks,
Qiliang