kernel/git/stable/linux.git/tools/net, branch linux-6.17.y

tools: ynl-gen: validate nested arrays

2025-11-13T20:37:24+00:00

[ Upstream commit 1d99aa4ed707c5630a7a7f067c8818e19167e3a1 ] In nested arrays don't require that the intermediate attribute type should be a valid attribute type, it might just be zero or an incrementing index, it is often not even used. See include/net/netlink.h about NLA_NESTED_ARRAY: > The difference to NLA_NESTED is the structure: > NLA_NESTED has the nested attributes directly inside > while an array has the nested attributes at another > level down and the attribute types directly in the > nesting don't matter. Example based on include/uapi/linux/wireguard.h: > WGDEVICE_A_PEERS: NLA_NESTED > 0: NLA_NESTED > WGPEER_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN > [..] > 0: NLA_NESTED > ... > ... Previous the check required that the nested type was valid in the parent attribute set, which in this case resolves to WGDEVICE_A_UNSPEC, which is YNL_PT_REJECT, and it took the early exit and returned YNL_PARSE_CB_ERROR. This patch renames the old nl_attr_validate() to __nl_attr_validate(), and creates a new inline function nl_attr_validate() to mimic the old one. The new __nl_attr_validate() takes the attribute type as an argument, so we can use it to validate attributes of a nested attribute, in the context of the parents attribute type, which in the above case is generated as: [WGDEVICE_A_PEERS] = { .name = "peers", .type = YNL_PT_NEST, .nest = &wireguard_wgpeer_nest, }, __nl_attr_validate() only checks if the attribute length is plausible for a given attribute type, so the .nest in the above example is not used. As the new inline function needs to be defined after ynl_attr_type(), then the definitions are moved down, so we avoid a forward declaration of ynl_attr_type(). Some other examples are NL80211_BAND_ATTR_FREQS (nest) and NL80211_ATTR_SUPPORTED_COMMANDS (u32) both in nl80211-user.c $ make -C tools/net/ynl/generated nl80211-user.c Signed-off-by: Asbjørn Sloth Tønnesen Reviewed-by: Jakub Kicinski Link: https://patch.msgid.link/20250915144301.725949-7-ast@fiberby.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

tools: ynl: avoid print_field when there is no reply

2025-11-13T20:36:42+00:00

[ Upstream commit e3966940559d52aa1800a008dcfeec218dd31f88 ] When request a none support device operation, there will be no reply. In this case, the len(desc) check will always be true, causing print_field to enter an infinite loop and crash the program. Example reproducer: # ethtool.py -c veth0 To fix this, return immediately if there is no reply. Fixes: f3d07b02b2b8 ("tools: ynl: ethtool testing tool") Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20251024125853.102916-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

tools: ynl: fix string attribute length to include null terminator

2025-11-13T20:36:42+00:00

[ Upstream commit 65f9c4c5888913c2cf5d2fc9454c83f9930d537d ] The ynl_attr_put_str() function was not including the null terminator in the attribute length calculation. This caused kernel to reject CTRL_CMD_GETFAMILY requests with EINVAL: "Attribute failed policy validation". For a 4-character family name like "dpll": - Sent: nla_len=8 (4 byte header + 4 byte string without null) - Expected: nla_len=9 (4 byte header + 5 byte string with null) The bug was introduced in commit 15d2540e0d62 ("tools: ynl: check for overflow of constructed messages") when refactoring from stpcpy() to strlen(). The original code correctly included the null terminator: end = stpcpy(ynl_attr_data(attr), str); attr->nla_len = NLA_HDRLEN + NLA_ALIGN(end - (char *)ynl_attr_data(attr)); Since stpcpy() returns a pointer past the null terminator, the length included it. The refactored version using strlen() omitted the +1. The fix also removes NLA_ALIGN() from nla_len calculation, since nla_len should contain actual attribute length, not aligned length. Alignment is only for calculating next attribute position. This makes the code consistent with ynl_attr_put(). CTRL_ATTR_FAMILY_NAME uses NLA_NUL_STRING policy which requires null terminator. Kernel validates with memchr() and rejects if not found. Fixes: 15d2540e0d62 ("tools: ynl: check for overflow of constructed messages") Signed-off-by: Petr Oros Tested-by: Ivan Vecera Reviewed-by: Ivan Vecera Link: https://lore.kernel.org/20251018151737.365485-3-zahari.doychev@linux.com Link: https://patch.msgid.link/20251024132438.351290-1-poros@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

tools: ynl: fix undefined variable name

2025-10-15T10:03:56+00:00

[ Upstream commit 7a3aaaa9fce710938c3557e5708ba5b00dd38226 ] This variable used in the error path was not defined according to Ruff. msg_format.attr_set is used instead, presumably the one that was supposed to be used originally. This is linked to Ruff error F821 [1]: An undefined name is likely to raise NameError at runtime. Fixes: 1769e2be4baa ("tools/net/ynl: Add 'sub-message' attribute decoding to ynl") Link: https://docs.astral.sh/ruff/rules/undefined-name/ [1] Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Donald Hunter Reviewed-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20250909-net-next-ynl-ruff-v1-1-238c2bccdd99@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

tools: ynl-gen: fix nested array counting

2025-09-03T22:18:34+00:00

The blamed commit introduced the concept of split attribute counting, and later allocating an array to hold them, however TypeArrayNest wasn't updated to use the new counting variable. Abbreviated example from tools/net/ynl/generated/nl80211-user.c: nl80211_if_combination_attributes_parse(...): unsigned int n_limits = 0; [...] ynl_attr_for_each(attr, nlh, yarg->ys->family->hdr_len) if (type == NL80211_IFACE_COMB_LIMITS) ynl_attr_for_each_nested(attr2, attr) dst->_count.limits++; if (n_limits) { dst->_count.limits = n_limits; /* allocate and parse attributes */ } In the above example n_limits is guaranteed to always be 0, hence the conditional is unsatisfiable and is optimized out. This patch changes the attribute counting to use n_limits++ in the attribute counting loop in the above example. Fixes: 58da455b31ba ("tools: ynl-gen: improve unwind on parsing errors") Signed-off-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20250902160001.760953-1-ast@fiberby.net Signed-off-by: Jakub Kicinski

tools: ynl-gen: print setters for multi-val attrs

2025-07-25T00:28:49+00:00

For basic types we "flatten" setters. If a request "a" has a simple nest "b" with value "val" we print helpers like: req_set_a_b(struct a *req, int val) { req->_present.a = 1; req->b._present.val = 1; req->b.val = ... } This is not possible for multi-attr because they have to be allocated dynamically by the user. Print "object level" setters so that user preparing the object doesn't have to futz with the presence bits and other YNL internals. Add the ability to pass in the variable name to generated setters. Using "req" here doesn't feel right, while the attr is part of a request it's not the request itself, so it seems cleaner to call it "obj". Example: static inline void netdev_queue_id_set_id(struct netdev_queue_id *obj, __u32 id) { obj->_present.id = 1; obj->id = id; } Reviewed-by: Donald Hunter Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20250723171046.4027470-5-kuba@kernel.org Signed-off-by: Jakub Kicinski

tools: ynl-gen: print alloc helper for multi-val attrs

2025-07-25T00:28:49+00:00

In general YNL provides allocation and free helpers for types. For pure nested structs which are used as multi-attr (and therefore have to be allocated dynamically) we already print a free helper as it's needed by free of the containing struct. Add printing of the alloc helper for consistency. The helper takes the number of entries to allocate as an argument, e.g.: static inline struct netdev_queue_id *netdev_queue_id_alloc(unsigned int n) { return calloc(n, sizeof(struct netdev_queue_id)); } Reviewed-by: Donald Hunter Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20250723171046.4027470-4-kuba@kernel.org Signed-off-by: Jakub Kicinski

tools: ynl-gen: move free printing to the print_type_full() helper

2025-07-25T00:28:49+00:00

Just to avoid making the main function even more enormous, before adding more things to print move the free printing to a helper which already prints the type. Reviewed-by: Donald Hunter Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20250723171046.4027470-3-kuba@kernel.org Signed-off-by: Jakub Kicinski

tools: ynl-gen: don't add suffix for pure types

2025-07-25T00:28:49+00:00

Don't add _req to helper names for pure types. We don't currently print those so it makes no difference to existing codegen. Reviewed-by: Donald Hunter Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20250723171046.4027470-2-kuba@kernel.org Signed-off-by: Jakub Kicinski

tools: ynl: support packing binary arrays of scalars

2025-07-17T23:13:58+00:00

We support decoding a binary type with a scalar subtype already, add support for sending such arrays to the kernel. While at it also support using "None" to indicate that the binary attribute should be empty. I couldn't decide whether empty binary should be [] or None, but there should be no harm in supporting both. Link: https://patch.msgid.link/20250716000331.1378807-4-kuba@kernel.org Signed-off-by: Jakub Kicinski