This is v4 of the series that fixes extra_subflows u8 underflow bugs
in the MPTCP userspace path manager.
extra_subflows is a u8 field in struct mptcp_pm_data. The userspace PM
increments it after __mptcp_subflow_connect() succeeds, but
__mptcp_subflow_connect() calls mptcp_pm_close_subflow() on failure to
roll back the pre-increment done by the kernel PM. Because the userspace
PM hasn't incremented yet at that point, this decrement is spurious and
causes extra_subflows to underflow from 0 to 255.
Patch 1 fixes the underflow by aligning the userspace PM with the kernel
PM: increment extra_subflows before calling __mptcp_subflow_connect(),
so the existing error path in subflow.c correctly rolls it back on
failure. This also eliminates the race window described in v3 patch 2
where the worker could decrement before the user thread increments.
Patch 2 adds a selftest to validate that subflow creation failure with
an unreachable address does not corrupt the extra_subflows counter.
Tao Cui (2):
mptcp: pm: fix extra_subflows underflow on userspace PM subflow
creation
selftests: mptcp: add test for extra_subflows underflow on userspace
PM
net/mptcp/pm_userspace.c | 14 ++++++++------
tools/testing/selftests/net/mptcp/mptcp_join.sh | 4 ++++
2 files changed, 12 insertions(+), 6 deletions(-)
---
Changes in v4:
- Rework patch 1 per Mat's review: instead of gating
mptcp_pm_close_subflow() on the PM type in subflow.c, move
extra_subflows++ before __mptcp_subflow_connect() in the userspace
PM to align with the kernel PM behavior. No changes to subflow.c.
- Simplify error handling in userspace PM: take pm.lock only on
failure for cleanup.
- Add selftest (patch 2) as suggested by Mat.
- Drop the previous race fix (v3 patch 2), as it is no longer needed
once the increment is moved before the call.
Changes in v3:
- Patch 2: move extra_subflows++ before release_sock(sk) to close
the race window, instead of relying solely on the underflow guard.
Changes in v2:
- Dropped the use-after-free fix.
- Split the underflow fix into two patches, one per code path.
v1:
https://lore.kernel.org/all/20260509075629.217791-2-cuitao@kylinos.cn/
v3:
https://lore.kernel.org/all/20260514132925.410184-1-cuitao@kylinos.cn/
--
2.43.0