[PATCH net-next 0/4] netlink: fix ynl spec tooling robustness bugs

[PATCH net-next 0/4] netlink: fix ynl spec tooling robustness bugs

[Taylor Bates]

Hello!

This series is intended to address several robustness bugs found in the ynl
tooling and the netlink-raw YAML specification.

These issues were found while writing a netlink-raw spec for the Bridge
VLAN family. However each stands independently of that work, and fixes
bugs in the parser that can be reproduced against the existing spec
definitions.

The patches in this series carry Fixes tags, but are all in developer
tooling and have no effect on the running kernel. That is why they have
been targeted at net-next rather than net.

Signed-off-by: Taylor Bates <tmbates12@gmail.com>
---
Taylor Bates (4):
      netlink: specs: fix duplicate if/then keys in netlink-raw schema
      tools: ynl: reject zero-length attributes instead of looping forever
      tools: ynl: stop find_kernel_root() spinning at the filesystem root
      tools: ynl: fix uapi generation for anonymous enums with documented entries

 Documentation/netlink/netlink-raw.yaml | 31 +++++++++++++++++--------------
 tools/net/ynl/pyynl/lib/ynl.py         |  4 ++++
 tools/net/ynl/pyynl/ynl_gen_c.py       | 13 ++++++++++---
 3 files changed, 31 insertions(+), 17 deletions(-)
---
base-commit: ab217fbb9b2169ce677b09a66558d5c3adcfbb76
change-id: 20260907-ynl-robustness-d62d9693cc12

Best regards,
--  
Taylor Bates <tmbates12@gmail.com>

[PATCH net-next 1/4] netlink: specs: fix duplicate if/then keys in netlink-raw schema

[Taylor Bates]

Currently netlink-raw.yaml contains two if keys and two then keys in a
single mapping that enforces a "len" for "pad" members and a "len" or
"struct" for binary members.

During validation PyYAML resolves duplicate keys last-wins, so only the
binary rule survives. Pad has not been validated since January 2024.

None of the current specs violate this rule, but this validation should
not be parser dependent and unspecified. Strict YAML validators such as
Red Hat's VS Code YAML extension and Adrien Verge's yamllint will
reject the netlink-raw.yaml schema:

Command:
  $ yamllint Documentation/netlink/netlink-raw.yaml

Output:
  185:13    error    duplication of key "if" in mapping  (key-duplicates)
  189:13    error    duplication of key "then" in mapping  (key-duplicates)

The following invalid netlink family spec will pass validation in the
current ynl tooling:

  # SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
  ---
  name: minimal-raw
  doc: Minimal netlink-raw family for schema validation testing.
  protocol: netlink-raw
  protonum: 0

  definitions:
    -
      name: test-struct
      type: struct
      members:
        -
          name: reserved
          type: pad
          # len intentionally omitted

  attribute-sets: []

  operations:
    list: []

Fixes: bf08f32c8ced ("tools/net/ynl: Add support for nested structs")
Signed-off-by: Taylor Bates <tmbates12@gmail.com>
---
 Documentation/netlink/netlink-raw.yaml | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml
index 4c436b59a34b..18ccfe05048a 100644
--- a/Documentation/netlink/netlink-raw.yaml
+++ b/Documentation/netlink/netlink-raw.yaml
@@ -176,20 +176,23 @@ properties:
               struct:
                 description: Name of the nested struct type.
                 type: string
-            if:
-              properties:
-                type:
-                  const: pad
-            then:
-              required: [ len ]
-            if:
-              properties:
-                type:
-                  const: binary
-            then:
-              oneOf:
-                - required: [ len ]
-                - required: [ struct ]
+            allOf:
+              -
+                if:
+                  properties:
+                    type:
+                      const: pad
+                then:
+                  required: [ len ]
+              -
+                if:
+                  properties:
+                    type:
+                      const: binary
+                then:
+                  oneOf:
+                    - required: [ len ]
+                    - required: [ struct ]
         # End genetlink-legacy
 
   attribute-sets:

-- 
2.55.0

[PATCH net-next 2/4] tools: ynl: reject zero-length attributes instead of looping forever

[Taylor Bates]

The following bug was found in the ynl tooling while parsing
MDBA_ROUTER_PORT entries on a real bridge device with IGMP snooping
enabled, not through fuzzing.

This occurs if the parser walks into a nested attribute containing a
headerless entry (such as MDBA_ROUTER_PORT) and reads the ifindex
parameter as a length, rather than data.

If the parser reads this now misaligned data and parses a field
containing a zero byte, it will run in an infinite loop. It will
continuously append empty attribute objects and consume 100% CPU until
it exhausts the system's memory.

The most straightforward way to trigger this systematically is as
follows:

  1. Create a bridge device with multicast_vlan_snooping enabled.
  2. Add a permanent multicast router port to the bridge that lands
     on ifindex 8. (The mcast_router 2 state ensures that its timer
     is zero.)
  3. Feed NlAttrs() from pyynl the MDBA_ROUTER_PORT netlink payload.

This example creates a bytes object that reproduces the same shape
as the payload:

  msg  = struct.pack('HH', 8, 1) + struct.pack('I', 0xdeadbeef)
  msg += struct.pack('HH', 0, 2)
  NlAttrs(msg)

Fixes: e4b48ed460d3 ("tools: ynl: add a completely generic client")
Signed-off-by: Taylor Bates <tmbates12@gmail.com>
---
Full reproducer, run under "unshare -Urn" so the namespace starts with
only lo and ifindex allocation restarts from 1:

  ip link add br0 type bridge vlan_filtering 1 mcast_snooping 1 \
      mcast_vlan_snooping 1
  ip link set br0 up
  n=0
  while :; do
      n=$((n + 1))
      ip link add d$n type dummy
      idx=$(ip -o link show d$n | cut -d: -f1 | tr -d ' ')
      [ $((idx & 0xffff)) = 8 ] && break
      [ $n -gt 200 ] && { echo "gave up"; exit 1; }
  done
  ip link set d$n master br0
  ip link set d$n up
  bridge vlan add dev d$n vid 10
  bridge vlan set dev d$n vid 10 mcast_router 2
  bridge vlan global set dev br0 vid 10 mcast_snooping 1

The BRIDGE_VLANDB_GOPTS_MCAST_ROUTER_PORTS payload the kernel then sends:

  34 00 02 00   MDBA_ROUTER, len 52
  30 00 01 00   MDBA_ROUTER_PORT, len 48
  08 00 00 00   bare ifindex 8, written by nla_put_nohdr()
  08 00 01 00   MDBA_ROUTER_PATTR_TIMER, len 8
  00 00 00 00   timer value, 0 for a permanent router

Read as a header, the ifindex claims eight bytes and consumes the
MDBA_ROUTER_PATTR_TIMER header along with itself. The walk then lands on
the timer value, four zero bytes, and nla_len is 0. full_len is 0 too,
so the offset never advances.
---
 tools/net/ynl/pyynl/lib/ynl.py | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/net/ynl/pyynl/lib/ynl.py b/tools/net/ynl/pyynl/lib/ynl.py
index 8682bf588e1f..375a15d83a34 100644
--- a/tools/net/ynl/pyynl/lib/ynl.py
+++ b/tools/net/ynl/pyynl/lib/ynl.py
@@ -317,6 +317,10 @@ class NlAttrs:
 
         while offset < len(msg):
             attr = NlAttr(msg, offset)
+            if attr.full_len < 4:
+                raise YnlException(
+                    f'Malformed attribute at offset {offset}: '
+                    f'length {attr.payload_len} is shorter than the header')
             offset += attr.full_len
             self.attrs.append(attr)
 

-- 
2.55.0

Re: [PATCH net-next 2/4] tools: ynl: reject zero-length attributes instead of looping forever

[Jakub Kicinski]

On Tue, 08 Sep 2026 19:45:08 -0400 Taylor Bates wrote:
> The BRIDGE_VLANDB_GOPTS_MCAST_ROUTER_PORTS payload the kernel then sends:
> 
>   34 00 02 00   MDBA_ROUTER, len 52
>   30 00 01 00   MDBA_ROUTER_PORT, len 48
>   08 00 00 00   bare ifindex 8, written by nla_put_nohdr()
>   08 00 01 00   MDBA_ROUTER_PATTR_TIMER, len 8
>   00 00 00 00   timer value, 0 for a permanent router

Sounds like the family outputs garbage and should not be supported.

>          while offset < len(msg):
>              attr = NlAttr(msg, offset)
> +            if attr.full_len < 4:
> +                raise YnlException(
> +                    f'Malformed attribute at offset {offset}: '
> +                    f'length {attr.payload_len} is shorter than the header')
>              offset += attr.full_len
>              self.attrs.append(attr)

Not sure i follow you logic. If anything I'd have written:

	if len(msg) - offset < 4:
		raise ...short, not overly verbose msg")

? But again, if the kernel is not outputting valid attrs that's not
YNL's problem. 

[PATCH net-next 3/4] tools: ynl: stop find_kernel_root() spinning at the filesystem root

[Taylor Bates]

In the current pyynl tooling, the find_kernel_root() function
contains a loop that climbs up the directory tree relative to the
spec file until it finds a MAINTAINERS file. If ynl_gen_c.py is run
in-tree it terminates properly in the root of the kernel tree.

The relative directory returned is then used to build the provenance
comment. The path of the root directory that it terminates at is
thrown away immediately at the call site:

  _, spec_kernel = find_kernel_root(args.spec)

However, if it is run out-of-tree and does not find a MAINTAINERS
file in any of the directories, find_kernel_root() reaches "/".
Since os.path.dirname() is idempotent at "/", the while True: has no
exit.

This can be reproduced on today's tree if the specs are copied to
a directory outside of the kernel tree:

  mkdir -p /tmp/ynl-oot/specs
  cp Documentation/netlink/netlink-raw.yaml /tmp/ynl-oot/
  cp Documentation/netlink/specs/rt-link.yaml /tmp/ynl-oot/specs/
  tools/net/ynl/pyynl/ynl_gen_c.py --spec /tmp/ynl-oot/specs/rt-link.yaml \
      --mode uapi --header

The fallback implemented in this patch still
provides a usable output:

  /* Do not edit directly, auto-generated from: */
  /*	tmp/ynl-oot/specs/rt-link.yaml */

Fixes: be5bea1cc0bf ("net: add basic C code generators for Netlink")
Signed-off-by: Taylor Bates <tmbates12@gmail.com>
---
 tools/net/ynl/pyynl/ynl_gen_c.py | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index 2b3483db1b60..1c422141d2d7 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -3449,7 +3449,12 @@ def find_kernel_root(full_path):
     sub_path = ''
     while True:
         sub_path = os.path.join(os.path.basename(full_path), sub_path)
-        full_path = os.path.dirname(full_path)
+        parent = os.path.dirname(full_path)
+        if parent == full_path:
+            # Reached the filesystem root without finding a kernel tree, fall
+            # back to the path given.
+            return None, sub_path[:-1]
+        full_path = parent
         maintainers = os.path.join(full_path, "MAINTAINERS")
         if os.path.exists(maintainers):
             return full_path, sub_path[:-1]

-- 
2.55.0

Re: [PATCH net-next 3/4] tools: ynl: stop find_kernel_root() spinning at the filesystem root

[Jakub Kicinski]

On Tue, 08 Sep 2026 19:45:09 -0400 Taylor Bates wrote:
> However, if it is run out-of-tree and does not find a MAINTAINERS
> file in any of the directories, find_kernel_root() reaches "/".
> Since os.path.dirname() is idempotent at "/", the while True: has no
> exit.

Not our intended use case, why would we care about people copying code
out of tree? if they do they can patch the generator as well.

[PATCH net-next 4/4] tools: ynl: fix uapi generation for anonymous enums with documented entries

[Taylor Bates]

In pyynl's current render_uapi() implementation there exists a check
that is intended to ensure that definitions of type "enum" or "flags"
have a doc entry before calling write_doc_line().

However, this check still passes for anonymous enums since
enum.has_doc() still evaluates as true, so they still take the kdoc
code path.

As a result, this path attempts to hang the entry docs off of
enum.enum_name (which is of type None), raising a TypeError.
Both the ovs_datapath.yaml and ovs_flow.yaml specs will fail to
generate uapi headers in today's tree:

  $ ynl_gen_c.py --spec Documentation/netlink/specs/ovs_datapath.yaml \
    --mode uapi --header

  Traceback (most recent call last):
    File "tools/net/ynl/pyynl/ynl_gen_c.py", line 3780, in <module>
      main()
      ~~~~^^
    File "tools/net/ynl/pyynl/ynl_gen_c.py", line 3511, in main
      render_uapi(parsed, cw)
      ~~~~~~~~~~~^^^^^^^^^^^^
    File "tools/net/ynl/pyynl/ynl_gen_c.py", line 3255, in render_uapi
      cw.write_doc_line(enum.enum_name + doc)
                        ~~~~~~~~~~~~~~~^~~~~
  TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

The fix implemented by this patch instead generates a plain comment
in this scenario as there is no kdoc identifier to hang the
documentation off of.

Fixes: 690e50dd69ee ("tools: ynl-gen: de-kdocify enums with no doc for entries")
Signed-off-by: Taylor Bates <tmbates12@gmail.com>
---
 tools/net/ynl/pyynl/ynl_gen_c.py | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index 1c422141d2d7..66a6dbe07125 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -3247,15 +3247,17 @@ def render_uapi(family, cw):
                 continue
 
             if enum.has_doc():
-                if enum.has_entry_doc():
+                if enum.has_entry_doc() and enum.enum_name:
                     cw.p('/**')
                     doc = ''
                     if 'doc' in enum:
                         doc = ' - ' + enum['doc']
                     cw.write_doc_line(enum.enum_name + doc)
                 else:
+                    # Render a plain comment, no kdoc identifier available
                     cw.p('/*')
-                    cw.write_doc_line(enum['doc'], indent=False)
+                    if 'doc' in enum:
+                        cw.write_doc_line(enum['doc'], indent=False)
                 for entry in enum.entries.values():
                     if entry.has_doc():
                         doc = '@' + entry.c_name + ': ' + entry['doc']

-- 
2.55.0

Re: [PATCH net-next 4/4] tools: ynl: fix uapi generation for anonymous enums with documented entries

[Jakub Kicinski]

On Tue, 08 Sep 2026 19:45:10 -0400 Taylor Bates wrote:
> However, this check still passes for anonymous enums since
> enum.has_doc() still evaluates as true, so they still take the kdoc
> code path.
> 
> As a result, this path attempts to hang the entry docs off of
> enum.enum_name (which is of type None), raising a TypeError.
> Both the ovs_datapath.yaml and ovs_flow.yaml specs will fail to
> generate uapi headers in today's tree:

The generator only supports what's needed for in-tree families.
Any changes have to be reviewed in the same series as the specs
that need them.

Re: [PATCH net-next 0/4] netlink: fix ynl spec tooling robustness bugs

[Jakub Kicinski]

On Tue, 08 Sep 2026 19:45:06 -0400 Taylor Bates wrote:
> This series is intended to address several robustness bugs found in the ynl
> tooling and the netlink-raw YAML specification.
> 
> These issues were found while writing a netlink-raw spec for the Bridge
> VLAN family. However each stands independently of that work, and fixes
> bugs in the parser that can be reproduced against the existing spec
> definitions.

Why are you doing this? What's your intended use?
YNL extensions for classic families are unlikely to be accepted.
It's definitely not a goal for us to backfill all the ancient baggage.

> The patches in this series carry Fixes tags, but are all in developer
> tooling and have no effect on the running kernel. That is why they have
> been targeted at net-next rather than net.

So you know that the Fixes tags are pointless and yet you add them?
Please, if it's not a bug that needs to go to LTS it should not have 
a Fixes tag :/

Re: [PATCH net-next 0/4] netlink: fix ynl spec tooling robustness bugs

[tmbates12]

On Thu, 10 Sep 2026 22:23:14 -0700 Jakub Kicinski wrote:
> Why are you doing this? What's your intended use?
> YNL extensions for classic families are unlikely to be accepted.
> It's definitely not a goal for us to backfill all the ancient baggage.

As part of work I've been doing on switchdev based ethernet switches
for configuration and state monitoring, I'd like to avoid having to rely
on shelling out to iproute2 to query bridge VLAN devices.
Parsing its output is fine as it can emit structured JSON
output, but as bridge(8) always resolves the ifindex to its interface
name, additional lookups are required in order to find the ifindex.

Is a bridge VLAN spec something you would consider at all, or should
I drop the idea before writing it up?

> So you know that the Fixes tags are pointless and yet you add them?
> Please, if it's not a bug that needs to go to LTS it should not have
> a Fixes tag :/

Understood, I will drop the Fixes: tags.

I will be dropping patches 2/4 and 3/4 based on your comments on each.
I'll drop 4/4 as well, since I'm not planning to submit the OVS spec
work it would need to go with.


On Thu, Sep 10, 2026 at 10:23 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 08 Sep 2026 19:45:06 -0400 Taylor Bates wrote:
> > This series is intended to address several robustness bugs found in the ynl
> > tooling and the netlink-raw YAML specification.
> >
> > These issues were found while writing a netlink-raw spec for the Bridge
> > VLAN family. However each stands independently of that work, and fixes
> > bugs in the parser that can be reproduced against the existing spec
> > definitions.
>
> Why are you doing this? What's your intended use?
> YNL extensions for classic families are unlikely to be accepted.
> It's definitely not a goal for us to backfill all the ancient baggage.
>
> > The patches in this series carry Fixes tags, but are all in developer
> > tooling and have no effect on the running kernel. That is why they have
> > been targeted at net-next rather than net.
>
> So you know that the Fixes tags are pointless and yet you add them?
> Please, if it's not a bug that needs to go to LTS it should not have
> a Fixes tag :/

Re: [PATCH net-next 0/4] netlink: fix ynl spec tooling robustness bugs

[Jakub Kicinski]

On Sat, 12 Sep 2026 13:35:16 -0400 tmbates12 wrote:
> On Thu, 10 Sep 2026 22:23:14 -0700 Jakub Kicinski wrote:
> > Why are you doing this? What's your intended use?
> > YNL extensions for classic families are unlikely to be accepted.
> > It's definitely not a goal for us to backfill all the ancient baggage.  
> 
> As part of work I've been doing on switchdev based ethernet switches
> for configuration and state monitoring, I'd like to avoid having to rely
> on shelling out to iproute2 to query bridge VLAN devices.
> Parsing its output is fine as it can emit structured JSON
> output, but as bridge(8) always resolves the ifindex to its interface
> name, additional lookups are required in order to find the ifindex.
> 
> Is a bridge VLAN spec something you would consider at all, or should
> I drop the idea before writing it up?

I see, so you have a real use for this.
Let's get patch 1 reposted and merged, and then send out the whole
thing, we can judge how much hacking it takes to support the bridge.

> > So you know that the Fixes tags are pointless and yet you add them?
> > Please, if it's not a bug that needs to go to LTS it should not have
> > a Fixes tag :/  
> 
> Understood, I will drop the Fixes: tags.
> 
> I will be dropping patches 2/4 and 3/4 based on your comments on each.
> I'll drop 4/4 as well, since I'm not planning to submit the OVS spec
> work it would need to go with.

Do you mean kernel side code gen for OVS? I thought we have specs for
most of OVS already, we just don't use them for kernel code gen (since
it's a pretty stable code base).

Re: [PATCH net-next 0/4] netlink: fix ynl spec tooling robustness bugs

[tmbates12]

On Mon, 14 Sep 2026 16:12:06 -0700 Jakub Kicinski wrote:
> Do you mean kernel side code gen for OVS? I thought we have specs for
> most of OVS already, we just don't use them for kernel code gen (since
> it's a pretty stable code base).

Sorry, I was unclear on this, I have a feeling that I misread your
earlier point,
I didn't mean to sound like I was proposing any OVS work. Neither on the
the spec nor the kernel code gen. I do agree that 4/4 doesn't have any
necessity pinned to anything in-tree with that context in mind now.

I'll be sending out the repost for 1/1 shortly, and once I flesh out the rest of
the doc keys in the yaml.

I'd assume that starting the bridge spec out as an RFC would be appropriate
while we see how much work it'll take, but I'd just like to confirm beforehand.