Re: [PATCH] mptcp: pm: don't WARN on re-announced addr in kernel PM

[Matthieu Baerts <matttbe@kernel.org>]

Hi Kalpan,

On 25/05/2026 22:19, Kalpan Jani wrote:
> syzkaller hit the WARN_ON_ONCE() in mptcp_pm_alloc_anno_list() with
> the in-kernel path manager, reached via
> mptcp_pm_create_subflow_or_signal_addr().
> 
> The WARN assumes the kernel PM can never reselect an address that is
> still in msk->pm.anno_list. That is not true: when an endpoint is
> removed and re-added while a previously sent ADD_ADDR is still
> awaiting its echo, the endpoint id becomes available again in
> id_avail_bitmap, but the matching anno_list entry (with its
> retransmit timer) is still alive. The in-progress guard in
> mptcp_pm_create_subflow_or_signal_addr() only checks
> BIT(MPTCP_ADD_ADDR_SIGNAL), which is already cleared once the option
> has been transmitted, so the address gets reselected and reaches
> mptcp_pm_alloc_anno_list() a second time.

From what I understand, it means that if a "signal" MPTCP endpoint is
removed the echo got received, the in-kernel PM will continue
retransmitting the ADD_ADDR. That doesn't seem correct. I didn't check
in the code, but I thought that the retransmit timer was at least
stopped, but maybe the entry was not removed from the list?

Does it also mean that if an ADD_ADDR echo is never received, the entry
is never removed, even after having reached the max retransmissions?
> This is a benign transient state, so drop the WARN. For the kernel
> PM, just bail out: the ADD_ADDR is already in flight, and the PM will
> be rescheduled once it completes (or once the stale entry's timer
> expires).

If I understand correctly, the transient state is not benign, and the
WARN should not be dropped.


Also, it would be nice to add a new test to validate that. Here, it
might be easier with a packetdrill test [1]: start with one sending an
ADD_ADDR [2], but don't send the echo, and instead, remove and re-add
the endpoint.

[1] https://github.com/multipath-tcp/packetdrill
[2]
https://github.com/multipath-tcp/packetdrill/blob/mptcp-net-next/gtests/net/mptcp/add_addr/add_addr4_server.pkt

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.