All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matttbe@kernel.org>
To: Gang Yan <gang.yan@linux.dev>, mptcp@lists.linux.dev
Cc: Gang Yan <yangang@kylinos.cn>
Subject: Re: [PATCH mptcp-next 0/2] mptcp: MIB counter for invalid option
Date: Wed, 12 Aug 2026 17:03:21 +0200	[thread overview]
Message-ID: <d5ac123f-51f0-45c1-856c-c4693fc17a33@kernel.org> (raw)
In-Reply-To: <20260812100550.148670-1-gang.yan@linux.dev>

Hi Gang,

On 12/08/2026 12:05, Gang Yan wrote:
> From: Gang Yan <yangang@kylinos.cn>
> 
> This series is designed for [1].
> 
> Patch 1 passes the 'net' to options parser, I used to use
> dev_net(skb->dev) for MIB counters, but the AI reported it is not
> suitable for this. This patch has no functional change.
> 
> Patch 2 adds the InvalidOptionRx counter, and increments it when
> receive the invalid options.
> 
> The packetdill testcase is submitted, and can be reviewed in [2].
> 
> [1] https://github.com/multipath-tcp/mptcp_net-next/issues/628
Thank you for the patches. Please next time add a comment on the GitHub
ticket: I already have the patches ready, but I had to wait (for
administration purposes) before sending them:

============

commit 8173df5a467cac6ed421bb832ac3ee675b490fa6 (b4/mptcp-mib-inval-opt)
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Jul 31 14:10:38 2026 +0200

    mptcp: options: reset parsing in case of invalidity

    When an invalid option is detected -- any unexpected suboptions
    combinations or use of invalid sizes -- the current behaviour is to
    ignore the currently parsed option.

    Receiving such invalid options is suspicious: either this is coming from
    a buggy host, or an attacker. In this case, it seems safer to drop any
    previously parsed MPTCP option from such packet.

    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

commit be5492962195d2988a9c508bc8ce4d3f55ac1da7
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Jul 29 20:01:45 2026 +0200

    mptcp: options: track invalid ones

    Any unexpected suboptions combinations or use of invalid sizes are
    suspicious: either it is coming from a buggy host, or an attacker.

    Better to track that with a new MIB counter.

    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

commit 684c6244b5b76d30aaf30d62597247485b89cdb3
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Mon Aug 3 20:24:02 2026 +0200

    mptcp: options: use a dedicated bit for csum reqd

    Instead of mixing that with suboptions: that's the only non-suboptions
    that is present in the 'suboptions' field.

    This even cause a workaround with OPTIONS_MPTCP_DSS to exclude this
    non-suboptions when checking which other ones are set.

    Move it to a dedicated free bit, and adapt the corresponding code.

    This is clearer like that.

    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

=========

In your version, I see that you increment the counter even when the
suboption is not invalid, e.g. the version or the hmac is not supported.
I don't think we should do that.

If that's OK for you, I can add a co-dev by on my patches.

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


      parent reply	other threads:[~2026-08-12 15:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 10:05 [PATCH mptcp-next 0/2] mptcp: MIB counter for invalid option Gang Yan
2026-08-12 10:05 ` [PATCH mptcp-next 1/2] mptcp: pass net namespace to options parser Gang Yan
2026-08-12 10:05 ` [PATCH mptcp-next 2/2] mptcp: add MIB counter for received invalid options Gang Yan
2026-08-12 10:16   ` sashiko-bot
2026-08-12 11:17 ` [PATCH mptcp-next 0/2] mptcp: MIB counter for invalid option MPTCP CI
2026-08-12 15:03 ` Matthieu Baerts [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5ac123f-51f0-45c1-856c-c4693fc17a33@kernel.org \
    --to=matttbe@kernel.org \
    --cc=gang.yan@linux.dev \
    --cc=mptcp@lists.linux.dev \
    --cc=yangang@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.