isisd: Fix NHLFE entry memory leaks #16855

zhou-run · 2024-09-18T09:01:35Z

Before adding an NHLFE entry, zebra calls nhlfe_nexthop_active_ipv4()/nhlfe_nexthop_active_ipv6() to check if there is a corresponding directly connected route for the next hop prefix of the NHLFE. If such a route exists, it directly overwrites the output interface of the NHLFE's next hop with the output interface of the directly connected route. If the output interface of the directly connected route is different from the output interface of the NHLFE's next hop, deleting the NHLFE entry later will fail because nhlfe_nhop_match() cannot find the same next hop address and output interface, leading to an NHLFE entry leak.

Of course, the above situation generally does not occur, but ISIS adjacency labels can cause issues.
Establishing neighbors in ISIS only requires the existence of the neighbor's IP address and does not need the neighbor's IP address to be in the same subnet as the local IP address. When zebra creates an adjacency label entry, it uses the neighbor's IP address as the next hop. If the neighbor's IP address is not in the same subnet as the local IP address and there is a local directly connected route with the neighbor's IP address prefix, it will result in an issue where the corresponding adjacency label entry in zebra cannot be deleted.

We cannot enforce that ISIS must establish neighbors using IPv4 and IPv6 addresses in the same subnet, but we can ensure that IPv4 or IPv6 addresses in different subnets do not create adjacency labels.

isisd/isis_sr.c

Before adding an NHLFE entry, zebra calls nhlfe_nexthop_active_ipv4()/nhlfe_nexthop_active_ipv6() to check if there is a corresponding directly connected route for the next hop prefix of the NHLFE. If such a route exists, it directly overwrites the output interface of the NHLFE's next hop with the output interface of the directly connected route. If the output interface of the directly connected route is different from the output interface of the NHLFE's next hop, deleting the NHLFE entry later will fail because nhlfe_nhop_match() cannot find the same next hop address and output interface, leading to an NHLFE entry leak. Establishing neighbors in ISIS only requires the existence of the neighbor's IP address and does not need the neighbor's IP address to be in the same subnet as the local IP address. When zebra creates an adjacency label entry, it uses the neighbor's IP address as the next hop. If the neighbor's IP address is not in the same subnet as the local IP address and there is a local directly connected route with the neighbor's IP address prefix, it will result in an issue where the corresponding adjacency label entry in zebra cannot be deleted. We cannot enforce that ISIS must establish neighbors using IPv4 and IPv6 addresses in the same subnet, but we can ensure that IPv4 or IPv6 addresses in different subnets do not create adjacency labels. Signed-off-by: zhou-run <[email protected]>

riw777

looks good

riw777 · 2024-09-24T14:08:31Z

failure is unrelated ... trying just the failed test again

frrbot bot added the isis label Sep 18, 2024

github-actions bot added size/M master labels Sep 18, 2024

zhou-run force-pushed the 202409131731 branch 2 times, most recently from 1f47f06 to 62d13f6 Compare September 18, 2024 09:14

donaldsharp reviewed Sep 18, 2024

View reviewed changes