Re: [PATCH mptcp-net v4] mptcp: pm: fix userspace PM address ID overflow when all IDs are exhausted

Matthieu Baerts <[email protected]>
Newsgroups dev.linux.lists.mptcp
Organization NGI0 Core
Message-ID <[email protected]>
Hi luoqing,

On 07/08/2026 09:41, luoqing wrote:
> From: Qing Luo <[email protected]>
> 
> When all MPTCP address IDs (1-255) are exhausted in the userspace PM,
> find_next_zero_bit() returns MPTCP_PM_MAX_ADDR_ID + 1 (256). This value
> overflows when stored in the u8 field e->addr.id, resulting in ID 0
> being stored and the entry being incorrectly added to the list.
> 
> ID 0 is reserved for the initial connection in MPTCP, so this overflow
> can cause address conflicts.
> 
> Note: the in-kernel PM already has an 'endpoints == MPTCP_PM_MAX_ADDR_ID'
> check in mptcp_pm_nl_append_new_local_addr() that returns -ERANGE before
> reaching find_next_zero_bit(), preventing this overflow. So this fix only
> addresses the userspace PM path.
> 
> Check the find_next_zero_bit() result against MPTCP_PM_MAX_ADDR_ID and
> return -ENOSPC if all IDs are truly exhausted. Move the ID allocation
> check before the memory allocation so that the error path does not need
> to free the allocated entry.
> 
> Fixes: 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs")
> Assisted-by: LLM
> Signed-off-by: Qing Luo <[email protected]>
> ---
> v4: Move the ID allocation check before the memory allocation so that the error path 
>     does not need to free the allocated entry
Thanks, now in our tree:

New patches for t/upstream-net and t/upstream:
- b57c0c6fddb3: mptcp: pm: fix userspace PM address ID overflow when all
IDs are exhausted
- Results: 4439056e6ccd..d0562342cb80 (export-net)
- Results: e8891858656d..f393de6a43c3 (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/1f6dc25f039e11595558280af68c916da4e86f71/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/3601198557ef7a1d08e411ac4ca4aa5e636d4e3e/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.