Re: [PATCH net 07/14] mptcp: pm: userspace: fix address ID overflow

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Spurious failure in mptcp_userspace_pm_append_new_local_addr when allocating a new ID if an address with ID 0 exists.
--

--- Patch [7]: [PATCH net 07/14] mptcp: pm: userspace: fix address ID overflow ---
commit 88d3db755130c825590998e405b9b270ff919205
Author: Qing Luo <luoqing@kylinos.cn>

mptcp: pm: userspace: fix address ID overflow

This commit fixes an overflow issue in the userspace PM when all MPTCP address
IDs (1-255) are exhausted. It adds a check against MPTCP_PM_MAX_ADDR_ID after
calling find_next_zero_bit(), returning -ENOSPC to prevent storing an
incorrect ID 0.

> diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
> index b94fbb483bf94..fab16d953dbfe 100644
> --- a/net/mptcp/pm_userspace.c
> +++ b/net/mptcp/pm_userspace.c
> @@ -69,6 +69,19 @@ static int mptcp_userspace_pm_append_new_local_addr(struct mptcp_sock *msk,
>  	}

[Severity: High]
This is a pre-existing issue, but does the loop just above here falsely
trigger a match if both IDs are 0?

In the preceding loop, we have:

	id_match = (e->addr.id == entry->addr.id);
	if (addr_match || id_match)
		break;

If needs_id is true, entry->addr.id is initially 0 as a placeholder. If an
existing address in userspace_pm_local_addr_list was previously added without
an ID attribute, it might have id == 0.

Could this cause id_match to evaluate to true (0 == 0), breaking the loop
prematurely and leading to a spurious -EINVAL failure? This might completely
break dynamic ID allocation and permanently reject new incoming or outgoing
subflow JOINs that require an ID.

>  	if (!addr_match && !id_match) {
> +		unsigned int id;
> +
> +		if (!entry->addr.id && needs_id) {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824-net-mptcp-misc-fixes-7-3-rc1-v1-0-a92309d121ca@kernel.org?part=7