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

From: Wang Zhaolong

Date: Wed Jul 08 2026 - 04:26:15 EST


> From: "Jing Wu"<realwujing@xxxxxxxxx>
> Date:  Wed, Jul 8, 2026, 3:57 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:33:36PM +0800, Wang Zhaolong wrote:
> > I do not want to make this a patch ownership discussion.
> 
> Let's be clear about the facts, then.
> 
> You reported the bug.  Our team fixed it — the next day.  May 28, our
> v1.  You confirmed on May 29 that our v3 fixes your reproducer.
> 
> Since then, you've posted three versions — v1, v2, v3 — that
> incrementally copy the work we developed and refined through seven
> iterations.  Your v2 copied our lock-move skeleton.  Your v3 copied the
> irq_chain_mutex rename, __must_hold(), and lockdep_assert_held() — all
> written by us, all reviewed by Jiri on our patches.
> 
> You list these as your own "Changes in v3" with zero attribution.
> 
> This is not a "patch ownership discussion."  You copied our code.  The
> kernel is GPLv2 — that means you can use the code, but you must
> preserve the copyright notices.  Co-developed-by is the mechanism for
> that.
> 
> You reported the bug — we fixed it first.  We credited you.  Now add
> the tags.
> 
> Jing
> 


Hi Jing,

This accusation is not acceptable.

My v1 was posted on May 27, before your v1, and it already made the core
locking change: move hash_mutex to serial_link_irq_chain() and keep 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

So the claim that my v2 copied your lock-move skeleton is false.

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

For v3, the irq_chain_mutex rename was made in response to Jiri's review
comment that hash_mutex was no longer an appropriate name.  The __must_hold()
and lockdep_assert_held() additions document the caller-held mutex after the
lock move; they are not the functional fix.

I do not agree to a Co-developed-by tag for my patch, and please do not add
Co-developed-by for me without my agreement and Signed-off-by.

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

Thanks,
Wang