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

[Jing Wu]

From: Qiliang Yuan <realwujing@xxxxxxxxx>

On Wed, Jul 08, 2026 at 08:03:55AM +0200, Jiri Slaby wrote:
> Ah, now I see you are fixing the same thing as:
> https://lore.kernel.org/all/20260708031115.3757150-1-wangzhaolong@xxxxxxxxx/
>
> I did not look up who of you was first.
>
> Looks like he reported and apparently tries to fix that too ;). You were
> obviously CCed, talk to them and don't send two patches for the same issue.

Wang reported Bugzilla #221579 and sent an initial patch on May 27.
I sent my v1 the next day (May 28), and have iterated with Wang's review
input across v1..v6 â?? the timeline shows Wang's v2 (Jul 8) was written
after and based on the direction of our v5/v6 series:

  v1: May 28, Qiliang    [PATCH] serial: 8250: fix use-after-free in IRQ chain handling
  v3: May 29, Wang       confirmed "v3 fixes the Bugzilla reproducer on my setup."
  v5: Jun 24, Qiliang    [PATCH v5] (with manual locking)
  v6: Jul 7,  Qiliang    [PATCH v6] (back to guard style)
  v2: Jul 8,  Wang       [PATCH v2] (same lock-move skeleton as v5/v6)

Wang's v2 has the same lock-move skeleton but is missing three pieces
we've added through review:

  - lockdep_assert_held() and __must_hold() in serial_get_or_create_irq_info()
  - hash_mutex covering the request_irq() error cleanup (use-after-free fix)
  - addressing both the use-after-free and "Unbalanced enable" races

I'll add Co-developed-by: Wang Zhaolong to the next revision.

> hash_mutex is no longer an appropriate name for this lock.

Ack, will rename in v7.

> Unrelated change.
> Unrelated and mainly unneeded change.

Ack, will drop both the blank-line removal and the return 0 change.

Thanks,
Qiliang