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

On Fri, Sep 18, 2026 at 06:36:56AM +0000, sashiko-bot@kernel.org wrote:

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

Thanks, I will fix all these byte order issue.

--

commit 18041b529d7678ae7bbdd8ee61a7fb4213ae6804
Author: Hangbin Liu [off-list ref]

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.

quoted

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

[ ... ]

quoted

@@ -277,6 +332,229 @@ attribute-sets:
       -
         name: fastopen-no-cookie
         type: u32

[ ... ]

quoted

+  -
+    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.

quoted

+      -
+        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().

[ ... ]

quoted

+  -
+    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.

[ ... ]

quoted

+      -
+        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.

[ ... ]

quoted

+  -
+    name: seg6-local
+    name-prefix: seg6-local-
+    header: linux/seg6_local.h
+    attributes:

[ ... ]

quoted

+      -
+        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