public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Felix Maurer <fmaurer@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Luka Gejak <luka.gejak@linux.dev>,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	netdev@vger.kernel.org, horms@kernel.org
Subject: Re: [PATCH net-next v5 1/2] net: hsr: require valid EOT supervision TLV
Date: Mon, 13 Apr 2026 11:14:46 +0200	[thread overview]
Message-ID: <ady0Bjkpiwm06Jmk@thinkpad> (raw)
In-Reply-To: <20260412133157.3b335e1b@kernel.org>

On Sun, Apr 12, 2026 at 01:31:57PM -0700, Jakub Kicinski wrote:
> On Sun, 12 Apr 2026 22:13:35 +0200 Luka Gejak wrote:
> > Regarding the TLV loop: I actually implemented a TLV walker in v4 [1]
> > for this exact reason, but I moved to strict sequential parsing in v5
> > based on reviewer's feedback to keep the implementation simple. Could
> > you please check if the approach used in v4 is what you had in mind?
> > If so, I will rebase that logic onto the memory safety fixes
> > (pskb_may_pull) from v5 and submit it as v6.
>
> That's not really what I had in mind. I was thinking of a loop which
> just skips the TLVs in order, leaving the parsing of known TLVs as is.
> But I've never used HSR maybe this sort of strict validation is somehow
> okay in HSR deployments.

Hi Jakub,

I'm chiming in here as I was one of the reviewers asking for the strict
validation. The HSR supervision frames have this TLV structure that may
appear to support optionals or (unknown) extensions of some kind. But
the standard just has two potential frame formats (for normal and RedBox
supervision frames), both of them completely specified. Also, the
supervision frames have a version field in the beginning. IMHO, this
leaves no room to put other TLVs there. Therefore, I don't think we gain
anything but unexpected behavior if we start accepting frames with
arbitrary additional TLVs/data.

Thanks,
   Felix


  parent reply	other threads:[~2026-04-13  9:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07 16:25 [PATCH net-next v5 0/2] net: hsr: strict supervision TLV validation luka.gejak
2026-04-07 16:25 ` [PATCH net-next v5 1/2] net: hsr: require valid EOT supervision TLV luka.gejak
2026-04-08  7:48   ` Fernando Fernandez Mancera
2026-04-08  8:05     ` Fernando Fernandez Mancera
2026-04-08  8:19       ` Luka Gejak
2026-04-08  9:32   ` Felix Maurer
2026-04-12 19:45   ` Jakub Kicinski
2026-04-12 20:13     ` Luka Gejak
2026-04-12 20:31       ` Jakub Kicinski
2026-04-12 20:46         ` Luka Gejak
2026-04-12 21:13           ` Jakub Kicinski
2026-04-13  9:14         ` Felix Maurer [this message]
2026-04-07 16:25 ` [PATCH net-next v5 2/2] net: hsr: reject unresolved interlink ifindex luka.gejak

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=ady0Bjkpiwm06Jmk@thinkpad \
    --to=fmaurer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=luka.gejak@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox