[frr]: Fix zebra NB RIB route lookup_next route_node lock under-run

Add FRR patch 0115 to drop the erroneous route_unlock_node() in the zebra
northbound oper-state RIB route iterator (lib_vrf_zebra_ribs_rib_route_
lookup_next). The node returned by lookup_next() seeds the get_next ->
route_next() iteration, which unlocks its input; releasing the lock in
lookup_next() under-runs the route_node lock to zero and aborts zebra
(assertion node->lock > 0) during the post-restart RIB sweep, wedging
vtysh and stalling bgpd.

Fixes: #27788
Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com>

Author: deepak-singhal0408

src/sonic-frr/patch/0115-zebra-keep-route_node-lock-in-NB-RIB-route-lookup_next.patch

@@ -0,0 +1,59 @@
+From 3996843162d6b5625edd831895dfe4cec9aa1f2e Mon Sep 17 00:00:00 2001
+From: Deepak Singhal <deepsinghal@microsoft.com>
+Date: Thu, 25 Jun 2026 05:14:26 +0000
+Subject: [PATCH] zebra: keep route_node lock in NB RIB route lookup_next
+
+The northbound oper-state iterator for /frr-vrf:lib/vrf/frr-zebra:zebra/
+ribs/rib/route uses lookup_next() to resume a yielded walk. lookup_next()
+called route_table_get_next(), which returns a route_node with the lock it
+acquired held, and then immediately released it with route_unlock_node()
+before returning the node.
+
+That node is carried back into the walk as args->list_entry and passed to
+lib_vrf_zebra_ribs_rib_route_get_next() -> srcdest_route_next() ->
+route_next(), which unlocks its input node as part of advancing. Because
+lookup_next() had already dropped the lock, route_next() under-runs the
+lock count to zero and trips:
+
+  zebra: assertion (node->lock > 0) failed
+
+aborting zebra. In SONiC this is hit during the post-restart RIB sweep when
+the FRR VRF oper-state notification walk (enabled by default since FRR 10.3)
+traverses a large RIB; the abort wedges vtysh and stalls bgpd on the zapi
+socket.
+
+lookup_entry() is a self-contained point lookup and correctly unlocks the
+node it returns. lookup_next(), by contrast, seeds an iteration whose first
+step (route_next) expects the carried node to still be locked. Remove the
+erroneous route_unlock_node() so the iterator lock contract holds.
+
+Fixes: https://github.com/sonic-net/sonic-buildimage/issues/27788
+Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com>
+---
+ zebra/zebra_nb_state.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/zebra/zebra_nb_state.c b/zebra/zebra_nb_state.c
+index 543d4b38b3..1f660f5550 100644
+--- a/zebra/zebra_nb_state.c
++++ b/zebra/zebra_nb_state.c
+@@ -399,8 +399,14 @@ lib_vrf_zebra_ribs_rib_route_lookup_next(struct nb_cb_lookup_entry_args *args)
+ 	if (!rn)
+ 		return NULL;
+ 
+-	route_unlock_node(rn);
+-
++	/*
++	 * Unlike lookup_entry (a self-contained point lookup), lookup_next
++	 * seeds the get_next iteration: the returned node is carried as
++	 * args->list_entry into get_next() -> route_next(), which unlocks its
++	 * input. The node returned by route_table_get_next() therefore must
++	 * keep the lock it carries; releasing it here under-runs the lock and
++	 * trips the route_unlock_node() assert when the walk resumes.
++	 */
+ 	return rn;
+ }
+ 
+-- 
+2.34.1
+

src/sonic-frr/patch/series

@@ -83,3 +83,4 @@
 0112-SONiC-ONLY-lib-build-add-configure-check-for-tc_mallinfo2-and-fallback.patch
 0113-zebra-Refactor-SRv6-netlink-code-to-remove-duplication.patch
 0114-Provide-interface-when-installing-uninstalling-SRv6-uA-SIDs.patch
+0115-zebra-keep-route_node-lock-in-NB-RIB-route-lookup_next.patch