Debian Patches

Status for frr/10.7.1-7

Patch Description Author Forwarded Bugs Origin Last update
debian/0001-ly_array_count-to-lya_count.patch LY_ARRAY_COUNT has been renamed to LYA_COUNT in libyang 6.4.0.
diff -Naurp frr.orig/lib/northbound_cli.c frr/lib/northbound_cli.c		 Daniel Baumann <daniel@debian.org> no
debian/0002-CVE-2026-119776.patch ospf6d: drop Hellos from non-link-local source addresses
ospf6_hello_recv() never checked that the Hello's IPv6 source address
is link-local, so a global-source Hello passed the area/instance/
Router-ID checks and created neighbors, rewrote stored neighbor
addresses via ospf6_neighbor_lladdr_set(), fed attacker-chosen
priority/DR/BDR fields into the election, and sent unicast DBDesc to
the bogus address, resetting a real adjacency. Drop Hello packets whose
source is not link-local before any neighbor processing; ospf6d has no
virtual-link support, so no legitimate global-source Hello exists for
it.

RFC 5340 Section 2.5: "On all OSPF interfaces except virtual links,
OSPF packets are sent using the interface's associated link-local
unicast address as the source address."		 Bing Shui <bingshui@smail.nju.edu.cn> no 2026-10-23
debian/0003-CVE-2026-119776.patch ospf6d: tighten packet address checks
The operator should be able to rely on the fact that OSPFv3 (aside from
virtual links, which we don't support yet) uses link-local addresses,
and thus does not need firewalling. Unfortunately, this wasn't being
enforced, potentially allowing successful adjacencies based on spoofed
packets from random internet sources.

On setups using OSPFv3 authentication trailers, the authentication
correctly prevents such adjacencies, but increased CPU usage may result.

This issue was highlighted by the recent FRRouting/frr#23935 PR.
Unfortunately, this was posted publicly, so it's a bit of a moot point
to attempt any kind of coordinated disclosure.		 David 'equinox' Lamparter <equinox@opensourcerouting.org> no 2026-11-02
upstream/0001-lib-Remove-ly_strerrcode-ly_strvecode-replacements.patch lib: Remove ly_strerrcode(), ly_strvecode() replacements
libyang 2.1.128 is now required by FRR.		 David Ward <david.ward@ll.mit.edu> no 2026-06-22
upstream/0002-lib-Remove-lyd_new_ext_term-lyd_change_term_bin-wrap.patch lib: Remove lyd_new_ext_term(), lyd_change_term_bin() wrappers

These functions were removed in libyang 4.8.0 and 5.3.0 respectively.
They are not called by FRR.		 David Ward <david.ward@ll.mit.edu> no 2026-06-22
upstream/0003-lib-Remove-parameter-from-wrapper-for-lyd_new_path2.patch lib: Remove parameter from wrapper for lyd_new_path2()
libyang 5.1.0 changed lyd_new_path2(), replacing a parameter of type
LYD_ANYDATA_VALUETYPE with a different parameter of type uint32_t.
The former was always set to 0 by FRR, and the latter can be set to 0
as well; but remove this parameter from the wrapper to avoid issues.

Also fix a variable name in the wrapper: the value size is in bytes.		 David Ward <david.ward@ll.mit.edu> no 2026-06-22
upstream/0004-lib-Adjust-parameters-to-wrapper-for-lyd_new_list.patch lib: Adjust parameters to wrapper for lyd_new_list()
lyd_new_list() and lyd_new_list3() have separate "module" and "name"
parameters. Expose these directly in the wrapper.		 David Ward <david.ward@ll.mit.edu> no 2026-06-22
upstream/0005-lib-Use-lyd_new_term-in-generic-getter-functions.patch lib: Use lyd_new_term() in generic getter functions
lyd_new_term_bin() was removed in libyang 5.1.3. Modify the generic
getter functions in FRR's northbound API to use lyd_new_term().

Prior to this, it was assumed nb_oper_uint{64,32}_get() could be used
with nodes of different integer types - although nb_oper_uint64_get()
was only used with uint64 nodes, and nb_oper_uint32_get() was unused
(and contained an invalid pointer cast). Now, those functions handle
uint{64,32} nodes only and return a validation error for other nodes.
Introduce separate functions to handle the other types.		 David Ward <david.ward@ll.mit.edu> no 2026-06-22
upstream/0006-lib-Replace-use-of-lyd_new_term_bin.patch lib: Replace use of lyd_new_term_bin()
lyd_new_term_bin() was removed in libyang 5.1.3. Adjust the get()
operational callbacks in FRR that used this function.		 David Ward <david.ward@ll.mit.edu> no 2026-06-22
upstream/0007-lib-Add-ly_yang_module_dir-to-search-directories.patch lib: Add ly_yang_module_dir() to search directories
In libyang 5.6.0, the internal binary modules were removed from the
library; instead the text versions are loaded from the filesystem.
The path needs to be provided to ly_ctx_new().		 David Ward <david.ward@ll.mit.edu> no 2026-10-11
upstream/0008-build-Remove-libyang-4.x-specific-warning.patch build: Remove libyang 4.x-specific warning
The binary encoding was not restored in libyang 5.x.		 David Ward <david.ward@ll.mit.edu> no 2026-10-11

All known versions for source package 'frr'

Links