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

[Wang Zhaolong]

> From: "Jing Wu"<realwujing@xxxxxxxxx>
> Date:  Wed, Jul 8, 2026, 4:08 PM
> Subject:  Re: [PATCH v6] serial: 8250: fix use-after-free in IRQ chain handling
> To: <wangzhaolong@xxxxxxxxx>
> Cc: <jirislaby@xxxxxxxxxx>, <gregkh@xxxxxxxxxxxxxxxxxxx>, <linux-serial@xxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <yuanql9@xxxxxxxxxxxxxxx>
> On Wed, Jul 08, 2026 at 03:53:26PM +0800, Wang Zhaolong wrote:
> > Just one technical clarification: my v1 also moved hash_mutex to
> > serial_link_irq_chain() and kept it held across irq_info lookup, i->head
> > publication, the first request_irq(), and the request_irq() failure cleanup
> 
> Your v1 commit message discusses only the "Unbalanced enable for IRQ"
> warning — it never mentions the use-after-free.  Our v1, one day later,
> was the first to identify and document *both* races.  You confirmed on
> May 29 that our v3 fixes your reproducer.
> 
> But the v1 lock-move is not the issue.  The issue is what happened after.
> 
> Our v5 (Jun 24) added lockdep_assert_held() and __must_hold() — reviewed
> by Jiri on our v4.  Our v7 (Jul 8) renamed hash_mutex to irq_chain_mutex
> — per Jiri's review on our v6.  Your v3 (Jul 8, after our v7) copies all
> three of these improvements and presents them in your changelog as:
> 
>   "Changes in v3:
>    - Rename hash_mutex to irq_chain_mutex
>    - Add __must_hold() and lockdep_assert_held()"
> 
> That is not a technical clarification.  That is taking work we wrote,
> reviewed by Jiri on our patches, and claiming it as your own.
> 
> Add the Co-developed-by tags.  We already added them for you on our v7.
> 
> Jing
> 

Hi Jing,

No.

A changelog entry describes what changed between my v2 and my v3.  It is not
a claim that nobody else ever wrote a similar line in another patch.

The functional fix in my series was already in my v1 on May 27.  Whether my
v1 commit message named the UAF or not does not change the code: holding the
same mutex across link and unlink closes that window too.  My v1 commit
message intentionally described the failure mode I had reproduced and
validated: the unbalanced IRQ enable warning.  I did not want to overstate the
impact beyond the evidence I had at the time.

The v3 rename follows Jiri's review comment that hash_mutex is no longer an
appropriate name.  The __must_hold() and lockdep_assert_held() annotations
document the locking rule after the mutex was moved to the caller.  They are
not the functional fix.

I do not agree that Co-developed-by is appropriate for my patch, and I do not
authorize adding a Co-developed-by tag for me without my Signed-off-by.

I am not going to continue this argument.  Maintainers can decide which patch,
if any, to take.

Thanks,
Wang