All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hangbin Liu" <hangbin.liu@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net-next 4/6] netlink: specs: rt-route: describe lwtunnel IP options
Date: Fri, 18 Sep 2026 06:36:58 +0000	[thread overview]
Message-ID: <20260918063658.80E4F1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260917-ynl_rt_encap-v1-4-fbbe6e680571@kylinos.cn>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] netlink: specs: missing byte-order property for lwtunnel-ip-opt-erspan index
- [Low] netlink: specs: missing max-len validation for lwtunnel-ip-opt-geneve data
--

commit 15d568f88486d1cb50af0dbb912eabab2c37d852
Author: Hangbin Liu <liuhangbin@kylinos.cn>

netlink: specs: rt-route: describe lwtunnel IP options

This commit replaces binary options in lwtunnel-ip and lwtunnel-ip6 with
a nested lwtunnel-ip-opts set. It also adds attribute sets for geneve, vxlan,
and erspan IP options to align with the kernel's definitions in lwtunnel.h.

> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index 0e236da140dc5..6030d7cb8d0d1 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
[ ... ]
> @@ -555,6 +557,59 @@ attribute-sets:
>        -
>          name: link
>          type: u32
> +  -
> +    name: lwtunnel-ip-opts
> +    name-prefix: lwtunnel-ip-opts-
> +    attributes:
> +      -
> +        name: geneve
> +        type: nest
> +        nested-attributes: lwtunnel-ip-opt-geneve
> +      -
> +        name: vxlan
> +        type: nest
> +        nested-attributes: lwtunnel-ip-opt-vxlan
> +      -
> +        name: erspan
> +        type: nest
> +        nested-attributes: lwtunnel-ip-opt-erspan
> +  -
> +    name: lwtunnel-ip-opt-geneve
> +    name-prefix: lwtunnel-ip-opt-geneve-
> +    attributes:
> +      -
> +        name: class
> +        type: u16
> +        byte-order: big-endian
> +      -
> +        name: type
> +        type: u8
> +      -
> +        name: data
> +        type: binary

[Severity: Low]
Does this binary attribute need a max-len validation check?

The kernel explicitly enforces a maximum length of 127 bytes for this
attribute in its Netlink policy:

net/ipv4/ip_tunnel_core.c:geneve_opt_policy[] {
    [LWTUNNEL_IP_OPT_GENEVE_DATA] = { .type = NLA_BINARY, .len = 127 },
}

Without a corresponding max-len constraint in the spec, auto-generated
tools will not catch oversized attributes locally before transmitting
them to the kernel.

> +  -
> +    name: lwtunnel-ip-opt-vxlan
> +    name-prefix: lwtunnel-ip-opt-vxlan-
> +    attributes:
> +      -
> +        name: gbp
> +        type: u32
> +  -
> +    name: lwtunnel-ip-opt-erspan
> +    name-prefix: lwtunnel-ip-opt-erspan-
> +    attributes:
> +      -
> +        name: ver
> +        type: u8
> +      -
> +        name: index
> +        type: u32

[Severity: Medium]
Will this result in an incorrect ERSPAN index on little-endian architectures?

The kernel parses this attribute using nla_get_be32():

net/ipv4/ip_tunnel_core.c:ip_tun_parse_opts_erspan() {
    ...
    attr = tb[LWTUNNEL_IP_OPT_ERSPAN_INDEX];
    md->u.index = nla_get_be32(attr);
    ...
}

Since the spec defines index as a u32 without the byte-order: big-endian
property, auto-generated tools will send the value in host byte order.
When run on a little-endian system, the kernel would then read a
byte-swapped, incorrect value, which would break the tunnel configuration.

> +      -
> +        name: dir
> +        type: u8
> +      -
> +        name: hwid
> +        type: u8

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917-ynl_rt_encap-v1-0-fbbe6e680571@kylinos.cn?part=4

  reply	other threads:[~2026-09-18  6:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17  6:35 [PATCH net-next 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
2026-09-17  6:35 ` [PATCH net-next 1/6] net: lwtunnel: change encap fill order Hangbin Liu
2026-09-18  6:36   ` sashiko-bot
2026-09-21  6:38   ` netdev-bot+sashiko
2026-09-17  6:35 ` [PATCH net-next 2/6] tools: ynl: convert enum selector to string for sub-message parsing Hangbin Liu
2026-09-18  6:36   ` sashiko-bot
2026-09-18  9:29     ` Hangbin Liu
2026-09-21  6:38   ` netdev-bot+sashiko
2026-09-17  6:35 ` [PATCH net-next 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support Hangbin Liu
2026-09-18  6:36   ` sashiko-bot
2026-09-18  7:51     ` Hangbin Liu
2026-09-21  6:38   ` netdev-bot+sashiko
2026-09-17  6:35 ` [PATCH net-next 4/6] netlink: specs: rt-route: describe lwtunnel IP options Hangbin Liu
2026-09-18  6:36   ` sashiko-bot [this message]
2026-09-18  8:02     ` Hangbin Liu
2026-09-21  6:38   ` netdev-bot+sashiko
2026-09-21  9:26     ` Hangbin Liu
2026-09-17  6:35 ` [PATCH net-next 5/6] netlink: specs: rt-route: describe lwt BPF program options Hangbin Liu
2026-09-18  6:36   ` sashiko-bot
2026-09-18  7:32     ` Hangbin Liu
2026-09-21  6:38   ` netdev-bot+sashiko
2026-09-21  9:46     ` Hangbin Liu
2026-09-17  6:35 ` [PATCH net-next 6/6] netlink: specs: rt-route: describe seg6-local actions, counters and flavors Hangbin Liu
2026-09-21  6:38   ` netdev-bot+sashiko

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=20260918063658.80E4F1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=hangbin.liu@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.