Re: [PATCH net-next 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] netlink: missing byte-order: big-endian in rt-route specs
--

commit 18041b529d7678ae7bbdd8ee61a7fb4213ae6804
Author: Hangbin Liu <liuhangbin@kylinos.cn>

netlink: specs: rt-route: add lwtunnel encap sub-message support

This commit adds lwtunnel encapsulation sub-message support to the rt-route
netlink specs, defining various tunnel attribute sets such as mpls, ip, ip6,
seg6, bpf, etc. It updates the yaml spec for rt-route and adds necessary
headers to the Makefile dependencies.

> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index 253037ea5176a..0e236da140dc5 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
[ ... ]
> @@ -277,6 +332,229 @@ attribute-sets:
>        -
>          name: fastopen-no-cookie
>          type: u32
[ ... ]
> +  -
> +    name: lwtunnel-ip
> +    name-prefix: lwtunnel-ip-
> +    header: linux/lwtunnel.h
> +    attributes:
> +      -
> +        name: id
> +        type: u64

[Severity: High]
Does this field need a byte-order: big-endian annotation? The kernel
reads LWTUNNEL_IP_ID as be64 using nla_get_be64(). Without the annotation,
YNL tools will byte-swap this on little-endian architectures, potentially
causing silent data corruption.

> +      -
> +        name: dst
> +        type: u32
> +        byte-order: big-endian
> +        display-hint: ipv4
> +      -
> +        name: src
> +        type: u32
> +        byte-order: big-endian
> +        display-hint: ipv4
> +      -
> +        name: ttl
> +        type: u8
> +      -
> +        name: tos
> +        type: u8
> +      -
> +        name: flags
> +        type: u16

[Severity: High]
Does this field also need a byte-order: big-endian annotation? The kernel
reads LWTUNNEL_IP_FLAGS as be16 using nla_get_be16().

[ ... ]
> +  -
> +    name: lwtunnel-ip6
> +    name-prefix: lwtunnel-ip6-
> +    header: linux/lwtunnel.h
> +    attributes:
> +      -
> +        name: id
> +        type: u64

[Severity: High]
Could this also be missing a byte-order: big-endian annotation? The kernel
reads LWTUNNEL_IP6_ID as be64.

[ ... ]
> +      -
> +        name: hoplimit
> +        type: u8
> +      -
> +        name: tc
> +        type: u8
> +      -
> +        name: flags
> +        type: u16

[Severity: High]
Could this also be missing a byte-order: big-endian annotation? The kernel
reads LWTUNNEL_IP6_FLAGS as be16.

[ ... ]
> +  -
> +    name: seg6-local
> +    name-prefix: seg6-local-
> +    header: linux/seg6_local.h
> +    attributes:
[ ... ]
> +      -
> +        name: table
> +        type: u32
> +      -
> +        name: nh4
> +        type: u32
> +        display-hint: ipv4

[Severity: High]
Does this field need a byte-order: big-endian annotation? SEG6_LOCAL_NH4 is
a raw IPv4 address and handled as a struct in_addr in the kernel, but here
it is typed as a native u32. This might cause YNL tools to silently
byte-swap the address on little-endian architectures.

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