[PATCH net v4 0/3] mptcp token hash ordering and token 0 lookups

[PATCH net v4 0/3] mptcp token hash ordering and token 0 lookups

[Hang Nan]

From: NanHang <2122295973@qq.com>

This series restores acquire ordering for the mptcp token lookup and fixes
two pre-existing defects in that hash table which ordering alone cannot
cover.

Patch 1 converts mptcp_token_get_sock() and mptcp_token_iter_next() to
refcount_inc_not_zero_acquire().  These sockets live in a
SLAB_TYPESAFE_BY_RCU slab, so the re-check of msk->token and sock_net()
after the increment only rejects a recycled socket if those loads are
ordered after the increment; without the acquire they can be satisfied
before it, against the previous owner's contents.

Patch 2 rejects token 0 in mptcp_token_get_sock().  Token 0 is never
assigned, but it is what mptcp_token_destroy() stores into a socket being
torn down, and what a freshly allocated msk holds until it is hashed.
For a lookup for token 0 both validations compare 0 with 0 and accept
such a socket; the token is copied from the wire by mptcp_parse_option(),
so a peer can ask for it.  The join path then uses the result, including
msk->pm.anno_list, which is initialised only later.

Patch 3 makes mptcp_token_iter_next() re-read the token after the
increment and drop the socket unless it is non-zero and still hashes to
the slot being walked, so a socket recycled in the same network namespace
is not handed to mptcp_diag or the userspace path manager before it is
initialised.

v1 -> v2:
 - Point the Fixes: tags at the commits that introduced each lockless
   lookup instead of at the refcount consolidation (sashiko review).

v2 -> v3:
 - Rewrite the rationale of the ordering patch: the acquire pairs with
   the SLAB_TYPESAFE_BY_RCU reuse window published by
   sock_init_data_uid(), not with mptcp_token_destroy() (sashiko review).
 - Add the token 0 and iterator patches, reported by the same review.

v3 -> v4:
 - Drop "net: core: take the reuseport migration reference with acquire
   ordering".  reuseport_migrate_sock() does not validate anything after
   the increment, and the listener state that could be raced is re-checked
   under queue->rskq_lock in inet_csk_reqsk_queue_add(), so the acquire
   orders nothing there (sashiko review).


Hang Nan (3):
  net: mptcp: take token lookup references with acquire ordering
  net: mptcp: reject token 0 in mptcp_token_get_sock()
  net: mptcp: verify the token slot in mptcp_token_iter_next()

 net/mptcp/token.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

-- 
2.47.3

Re: [PATCH net v4 0/3] mptcp token hash ordering and token 0 lookups

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by LLM and not proven at runtime). If it was triggered
   please include the symptoms, like the stack trace or kernel messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account.

*IMPORTANT*: If you do repost (for other reasons) - please include
the relevant info in the cover letter or commit messages.
-- 
The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.