[frr]: Fix zebra NB RIB route lookup_next route_node lock under-run (backport to 202608) (#2629)

#### Why I did it

Backport of sonic-net/sonic-buildimage#28094
(fixes sonic-net/sonic-buildimage#27788) to
the `202608` release branch. The master PR carries the `Cherry Pick
Conflict_msft-202608` label because the auto cherry-pick did not apply,
so this is the manual backport PR.

The bug: the zebra northbound oper-state RIB route iterator
(`lib_vrf_zebra_ribs_rib_route_lookup_next`) erroneously calls
`route_unlock_node()` on the node it returns. That node 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.

##### Work item tracking
- Microsoft ADO **(number only)**: N/A

#### How I did it

Cherry-picked the merged master commit
`0361265da273e4a08d03831c1515e041e4ba3de6` (the FRR `route_node` lock
fix).

Conflict resolution: the only conflict was in
`src/sonic-frr/patch/series`. On master the fix is registered as `0116`,
right after an unrelated patch
(`0115-zebra-Update-promiscuity-flag-silently...`, which touches
`zebra/if_netlink.c`) that is **not** present on `202608`. Since the fix
touches `zebra/zebra_nb_state.c` (a different file) and is independent
of that unrelated patch, it was registered at 202608's next free slot
**`0115`** (series ended at `0114`) and the unrelated promiscuity patch
was not carried. The patch body is byte-identical to master's.

Base parity: the FRR submodule pin is byte-identical
(`4cb6d9e6bfe4ad503d1fab21e6f665804b0649ac`) on the master parent, the
master fix commit, and `202608` — so the fix applies onto identical FRR
source.

#### How to verify it

- Applied the full `202608` FRR patch series (all 84 patches, including
the backported fix) in order onto the pinned FRR source `4cb6d9e6...` —
every patch applies cleanly; the fix integrates at its `lookup_next`
region with no overlap from preceding patches.
- Behavior was A/B-validated on master in
sonic-net/sonic-buildimage#28094: the zebra
abort artifact is present without the fix and absent with it. Because
the FRR base is byte-identical on `202608`, that validation carries
over.
- Full build + integration is covered by this PR's CI on the `202608`
base.

#### Which release branch to backport (provide reason below if selected)

- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [ ] 202505
- [ ] 202511

This PR **is** the release-branch backport (base = `202608`), so no
further backport checkbox is selected.

#### Tested branch (Please provide the tested image version)

- [ ] 202608 (FRR patch series apply verified against pinned FRR
`4cb6d9e6`; behavior verified on master per
sonic-net/sonic-buildimage#28094)

#### Description for the changelog

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

#### Link to config_db schema for YANG module changes

N/A

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,60 @@
+From 19e6c1b652a4fb7263108d3b65b9b84d2b3f2d31 Mon Sep 17 00:00:00 2001
+From: Deepak Singhal <deepsinghal@microsoft.com>
+Date: Wed, 1 Jul 2026 18:07:22 +0000
+Subject: [PATCH] zebra: keep route_node lock in NB RIB route lookup_next
+
+The northbound oper-state iterator for the
+/frr-vrf:lib/vrf/frr-zebra:zebra/ribs/rib/route list uses lookup_next()
+to resume a yielded walk. lookup_next() calls 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. This is hit when the oper-state notification walk (on by
+default since the FRR VRF YANG state was added) traverses a large RIB
+and yields, then resumes through lookup_next().
+
+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.
+
+Link: 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..d1d214281f 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 lib_vrf_zebra_ribs_rib_route_lookup_entry() (a self-contained
++	 * point lookup), this function seeds the get_next iteration: the
++	 * returned node is carried as args->list_entry into
++	 * lib_vrf_zebra_ribs_rib_route_get_next() -> srcdest_route_next() ->
++	 * route_next(), which unlocks its input node. The node returned by
++	 * route_table_get_next() must therefore keep the lock it carries.
++	 */
+ 	return rn;
+ }
+ 
+-- 
+2.34.1
+

src/sonic-frr/patch/series

@@ -82,3 +82,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