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

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

[Kalpan Jani]

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.

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).

Fixes: cd7c957f936f ("mptcp: pm: don't try to create sf if alloc failed")
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/620
Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
---
 net/mptcp/pm.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
index 3e770c7407e1..e75c97c1f1f2 100644
--- a/net/mptcp/pm.c
+++ b/net/mptcp/pm.c
@@ -443,7 +443,14 @@ bool mptcp_pm_alloc_anno_list(struct mptcp_sock *msk,
 	add_entry = mptcp_lookup_anno_list_by_saddr(msk, addr);
 
 	if (add_entry) {
-		if (WARN_ON_ONCE(mptcp_pm_is_kernel(msk)))
+		/* The kernel PM can legitimately reselect an address whose
+		 * previous ADD_ADDR is still pending (option already sent,
+		 * echo not yet received) when the matching endpoint is
+		 * removed and re-added before the announcement completes.
+		 * Don't re-announce it: the in-flight ADD_ADDR will finish
+		 * on its own and the PM will be rescheduled afterwards.
+		 */
+		if (mptcp_pm_is_kernel(msk))
 			return false;
 
 		goto reset_timer;
-- 
2.43.0

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

[MPTCP CI]

Hi Kalpan,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 1 failed test(s): packetdrill_dss ⚠️ 
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/26401003887

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/0d0a433a605b
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1100453


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

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

[Matthieu Baerts]

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.

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

[Kalpan Jani]

Hi Matt,

Thank you for the review.

On 26/05/2026 ..:.., Matthieu Baerts wrote:
>> The WARN assumes the kernel PM can never reselect an address that is
>> still in msk->pm.anno_list. That is not true: [...]
>
> 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?

You are right to expect the teardown. I checked the code, and it is not
uniform across the two removal paths:

- For a non-zero id endpoint, mptcp_nl_remove_subflow_and_signal_addr()
  -> mptcp_pm_remove_anno_addr() -> mptcp_remove_anno_list_by_saddr()
  -> mptcp_pm_del_add_timer(.., false): the timer is stopped and the
  anno_list entry is unlinked and freed. This path is fine.

- For the id 0 endpoint, mptcp_nl_remove_id_zero_address() does NOT
  call that teardown. It only queues a RM_ADDR and marks the id as
  available again; the pending anno_list entry and its armed timer are
  left alive.

So a stale entry can only survive on the id 0 removal path. When that
endpoint is re-added, the kernel PM reselects id 0, reaches
mptcp_pm_alloc_anno_list() a second time, finds the stale entry and
hits the WARN. That is the actual bug here.

> 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?

Yes. In mptcp_pm_add_timer(), once retrans_times reaches
ADD_ADDR_RETRANS_MAX the timer stops re-arming (timeout = 0), but the
anno_list entry itself is not freed there; it stays on the list until
the endpoint is removed.

>> This is a benign transient state, so drop the WARN. [...]
>
> If I understand correctly, the transient state is not benign, and the
> WARN should not be dropped.

Agreed. I will drop this patch. The WARN is a valid assertion; the fix
should keep it and instead make the id 0 removal path tear down the
pending ADD_ADDR, mirroring the non-zero id path (drop the anno_list
entry, stop its timer, and decrement add_addr_signaled if it had been
announced). I will send that as v2.

> Also, it would be nice to add a new test to validate that. Here, it
> might be easier with a packetdrill test [1] [...]

Will do. I will add a packetdrill test that sends an ADD_ADDR, withholds
the echo, and then removes and re-adds the endpoint, based on
add_addr4_server.pkt.

Cheers,
Kalpan Jani




From: Matthieu Baerts <matttbe@kernel.org>
To: "Kalpan Jani"<kalpan.jani@mpiricsoftware.com>, <mptcp@lists.linux.dev>
Cc: <martineau@kernel.org>, <pabeni@redhat.com>, <janak@mpiric.us>, <shardul.b@mpiricsoftware.com>, <kalpanjani009@gmail.com>, <shardulsb08@gmail.com>
Date: Tue, 26 May 2026 14:09:26 +0530
Subject: Re: [PATCH] mptcp: pm: don't WARN on re-announced addr in kernel PM

 > 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.
 > 
 > 

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

[Matthieu Baerts]

Hi Kalpan,

On 26/05/2026 21:15, Kalpan Jani wrote:
> Hi Matt,
> 
> Thank you for the review.
> 
> On 26/05/2026 ..:.., Matthieu Baerts wrote:
>>> The WARN assumes the kernel PM can never reselect an address that is
>>> still in msk->pm.anno_list. That is not true: [...]
>>
>> 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?
> 
> You are right to expect the teardown. I checked the code, and it is not
> uniform across the two removal paths:
> 
> - For a non-zero id endpoint, mptcp_nl_remove_subflow_and_signal_addr()
>   -> mptcp_pm_remove_anno_addr() -> mptcp_remove_anno_list_by_saddr()
>   -> mptcp_pm_del_add_timer(.., false): the timer is stopped and the
>   anno_list entry is unlinked and freed. This path is fine.
> 
> - For the id 0 endpoint, mptcp_nl_remove_id_zero_address() does NOT
>   call that teardown. It only queues a RM_ADDR and marks the id as
>   available again; the pending anno_list entry and its armed timer are
>   left alive.
> 
> So a stale entry can only survive on the id 0 removal path. When that
> endpoint is re-added, the kernel PM reselects id 0, reaches
> mptcp_pm_alloc_anno_list() a second time, finds the stale entry and
> hits the WARN. That is the actual bug here.

I guess there were some confusions at some points that the ID 0 wouldn't
be sent as an ADD_ADDR. But that can be the case when the linked address
is removed, then re-added. Then, I guess to have the bug, you need to
create a connection, with an extra subflow, then remove and re-add the
endpoint linked to the initial subflow, and repeat this once more to hit
the bug, no?

>> 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?
> 
> Yes. In mptcp_pm_add_timer(), once retrans_times reaches
> ADD_ADDR_RETRANS_MAX the timer stops re-arming (timeout = 0), but the
> anno_list entry itself is not freed there; it stays on the list until
> the endpoint is removed.

Only for the ID0, when re-added then.

>>> This is a benign transient state, so drop the WARN. [...]
>>
>> If I understand correctly, the transient state is not benign, and the
>> WARN should not be dropped.
> 
> Agreed. I will drop this patch. The WARN is a valid assertion; the fix
> should keep it and instead make the id 0 removal path tear down the
> pending ADD_ADDR, mirroring the non-zero id path (drop the anno_list
> entry, stop its timer, and decrement add_addr_signaled if it had been
> announced). I will send that as v2.

Thanks!

>> Also, it would be nice to add a new test to validate that. Here, it
>> might be easier with a packetdrill test [1] [...]
> 
> Will do. I will add a packetdrill test that sends an ADD_ADDR, withholds
> the echo, and then removes and re-adds the endpoint, based on
> add_addr4_server.pkt.
See above: you might need an extra subflow (see the tests in mp_join),
and re-add the endpoint twice, because once is enough to trigger the
fact the entry is not removed, but not enough to hit the WARN if I
understood correctly.

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