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, 3:39 PM
> Subject:  Re: [PATCH v6] serial: 8250: fix use-after-free in IRQ chain handling
> To: <jirislaby@xxxxxxxxxx>
> Cc: <gregkh@xxxxxxxxxxxxxxxxxxx>, <avorontsov@xxxxxxxxxxxxx>, <alan@xxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <linux-serial@xxxxxxxxxxxxxxx>, <wangzhaolong@xxxxxxxxx>, <yuanql9@xxxxxxxxxxxxxxx>
> 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.
> 
> I sent a v7 [1] addressing the three review items you raised, and added
> Co-developed-by: Wang Zhaolong and Qiliang Yuan.
> 
> Wang has just posted a v3 [2] which copies the very same changes from
> our series — irq_chain_mutex rename, __must_hold(), lockdep_assert_held()
> — without any acknowledgment.  No Co-developed-by, no mention of our
> series in the changelog.  It presents these as his own improvements.
> 
> The full timeline, for the record:
> 
>   May 27  Wang v1 — only the THRE test race, no use-after-free fix

Hi Jing,

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:

  https://lore.kernel.org/r/20260527092052.2086342-1-wangzhaolong@xxxxxxxxx

Since serial_unlink_irq_chain() takes the same mutex before free_irq() and
serial_do_unlink()/kfree(i), that also closes the irq_info UAF window.  My
commit message focused on the IRQ warning because that was the failure I
reported and reproduced.

>   May 28  Our v1 — both races, full fix
>   May 29  Wang on our v3 thread: "v3 fixes the Bugzilla reproducer"
>   Jun 24  Our v5 — added __must_hold() and lockdep_assert_held()
>   Jul  7  Our v6 — back to guard style
>   Jul  8  Our v7 — renamed hash_mutex to irq_chain_mutex (per Jiri)
>   Jul  8  Wang v3 — copies the rename, __must_hold(), lockdep_assert_held()
>                   from our v5/v7, claims as own work
> 
> Wang's v2 (Jul 8) was posted after our v5 and v6 and uses the same
> lock-move skeleton.  His v3 (Jul 8) was posted after our v7 and copies
> the irq_chain_mutex rename and __must_hold()/lockdep_assert_held() that
> we added in v5 and v7 — yet his changelog gives no credit.
> 
> I've been happy to add him as co-developer on our v7.  I would expect
> the same basic courtesy in return, but apparently that's too much to
> ask.
> 
> [1] https://lore.kernel.org/r/20260708-bug-221579-8250-shared-irq-race-v7-1-xxx@xxxxxxxxx
> [2] https://lore.kernel.org/all/20260708072306.3921604-1-wangzhaolong@xxxxxxxxx/
> 
> Thanks,
> Jing
> 

 I do not want to keep tracking or arguing about this issue. My only goal is to get this
regression fixed upstream.

Thanks,
Wang