bgpd
"default-originate" shouldn't withdraw non-default routes
Ensure community data is freed in some cases.
Ensure that the correct aspath is free'd
Fix error handling when receiving bgp prefix sid attribute
Fix format overflow for graceful-restart debug logs
Fix null argument warning
Include unsuppress-map as a valid outgoing policy
Make `suppress-fib-pending` clear peering
Prevent from one more cve triggering this place
doc
Add param range for graceful-restart helper supported-grace-time
isisd
Fix heap-after-free with prefix sid
Need to link directly against libyang
lib
Check for not being a blackhole route
Do not convert evpn prefixes into ipv4/ipv6 if not needed
ospf6d
Ospfv3 route change comparision fixed for asbr-only change
Prevent heap-buffer-overflow with unknown type
ospfd
Correct opaque lsa extended parser
Fix ospf dead-interval minimal hello-multiplier param range
Fix the bug where ip_ospf_dead-interval_minimal_hello-multiplier did not reset hello timer
Protect call to get_edge() in ospf_te.c
Solved crash in ri parsing with ospf te
pbrd
Fix pbr handling for last rule deletion
pimd
Fix crash unconfiguring rp keepalive timer
Fix crash when configuring ssmpingd
Fix dr-priority range
Fix null register before aging out reg-stop
Fix order of operations for evaluating join
Re-evaluated s,g oils upon rp changes and for empty sg upstream oils
Fix crash when mixing ssm/any-source joins
tests
Check for 0.0.0.0/1 in bgp_default_route
vtysh
Show `ip ospf network ...` even if it's not the same as the interface type
zebra
Deny the routes if ip protocol cli refers to an undefined rmap
Fix crash if macvlan link in another netns
Fix nhg out of sync between zebra and kernel
Re-install dependent nhgs on interface up
Re-install nhg on interface up
The dplane_fpm_nl return path leaks memory
Keelan10 [Wed, 5 Jun 2024 10:34:18 +0000 (13:34 +0300)]
nhrpd: Fix nhrp_peer leak
- Addressed memory leak by removing `&c->peer_notifier` from the notifier list on termination. Retaining it caused the notifier list to stay active, preventing the deletion of `c->cur.peer`
thereby causing a memory leak.
- Reordered termination steps to call `vrf_terminate` before `nhrp_vc_terminate`, preventing a heap-use-after-free issue when `nhrp_vc_notify_del` is invoked in `nhrp_peer_check_delete`.
- Added an if statement to avoid passing NULL as hash to `hash_release`, which leads to a SIGSEGV.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in nhrp_topo.test_nhrp_topo/r1.asan.nhrpd.20265
Direct leak of 112 byte(s) in 1 object(s) allocated from:
#0 0x7f80270c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f8026ac1eb8 in qmalloc lib/memory.c:100
#2 0x560fd648f0a6 in nhrp_peer_create nhrpd/nhrp_peer.c:175
#3 0x7f8026a88d3f in hash_get lib/hash.c:147
#4 0x560fd6490a5d in nhrp_peer_get nhrpd/nhrp_peer.c:228
#5 0x560fd648a51a in nhrp_nhs_resolve_cb nhrpd/nhrp_nhs.c:297
#6 0x7f80266b000f in resolver_cb_literal lib/resolver.c:234
#7 0x7f8026b62e0e in event_call lib/event.c:1969
#8 0x7f8026aa5437 in frr_run lib/libfrr.c:1213
#9 0x560fd6488b4f in main nhrpd/nhrp_main.c:166
#10 0x7f8025eb2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 112 byte(s) leaked in 1 allocation(s).
***********************************************************************************
***********************************************************************************
Address Sanitizer Error detected in nhrp_topo.test_nhrp_topo/r2.asan.nhrpd.20400
Direct leak of 112 byte(s) in 1 object(s) allocated from:
#0 0x7fb6e3ca5b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fb6e369deb8 in qmalloc lib/memory.c:100
#2 0x562652de40a6 in nhrp_peer_create nhrpd/nhrp_peer.c:175
#3 0x7fb6e3664d3f in hash_get lib/hash.c:147
#4 0x562652de5a5d in nhrp_peer_get nhrpd/nhrp_peer.c:228
#5 0x562652de1e8e in nhrp_packet_recvraw nhrpd/nhrp_packet.c:325
#6 0x7fb6e373ee0e in event_call lib/event.c:1969
#7 0x7fb6e3681437 in frr_run lib/libfrr.c:1213
#8 0x562652dddb4f in main nhrpd/nhrp_main.c:166
#9 0x7fb6e2a8ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 112 byte(s) leaked in 1 allocation(s).
***********************************************************************************
```
David Lamparter [Sat, 16 Sep 2023 12:17:24 +0000 (14:17 +0200)]
ospf6d: fix uninitialized warnings
GCC 13.2.0 complains:
```
ospf6d/ospf6_intra.c:139:25: error: ‘json_arr’ may be used uninitialized [-Werror=maybe-uninitialized]
ospf6d/ospf6_intra.c:485:20: error: ‘json_arr’ may be used uninitialized [-Werror=maybe-uninitialized]
```
Iggy Frankovic [Thu, 30 May 2024 11:59:54 +0000 (07:59 -0400)]
ospf6d: Prevent heap-buffer-overflow with unknown type
When parsing a osf6 grace lsa field and we receive an
unknown tlv type, ospf6d was not incrementing the pointer
to get beyond the tlv. Leaving a situation where ospf6d
would parse the packet incorrectly.
There is no reason to call `igmp_anysource_forward_stop()` inside a call to
`igmp_get_source_by_addr()`; not only it is not expected for a "get" function
to perform such an action, but also the decision to start/stop forwarding is
already handled correctly by pim outside `igmp_get_source_by_addr()`.
That call was left there from the days pim was initially imported into the sources.
The problem/crash was happening because `igmp_find_source_by_addr()` would fail to
find the group/source combo when mixing `(*, G)` and `(S, G)`. When having an existing
flow `(*, G)`, and a new `(S, G)` igmp is received, a new entry is correctly created.
`igmp_anysource_forward_stop(group)` always stops and eventually frees `(*, G)`, even
when the new igmp is `(S, G)`, leaving a bad state. I.e, the new entry for `(S, G)`
causes `(*, G)` to be deleted.
Tested the fix with multiple receivers on the same interface with several ssm and
any source senders and receivers with various combination of start/stop orders and
they all worked correctly.
Donatas Abraitis [Tue, 13 Jun 2023 13:08:24 +0000 (16:08 +0300)]
bgpd: Use enum bgp_create_error_code as argument in header
```
bgpd/bgp_vty.c:865:5: warning: conflicting types for ‘bgp_vty_return’ due to enum/integer mismatch; have ‘int(struct vty *, enum bgp_create_error_code)’ [-Wenum-int-mismatch]
865 | int bgp_vty_return(struct vty *vty, enum bgp_create_error_code ret)
| ^~~~~~~~~~~~~~
In file included from ./bgpd/bgp_mplsvpn.h:15,
from bgpd/bgp_vty.c:48:
./bgpd/bgp_vty.h:148:12: note: previous declaration of ‘bgp_vty_return’ with type ‘int(struct vty *, int)’
148 | extern int bgp_vty_return(struct vty *vty, int ret);
| ^~~~~~~~~~~~~~
```
Donatas Abraitis [Tue, 13 Jun 2023 13:01:40 +0000 (16:01 +0300)]
bgpd: Use enum bgp_fsm_state_progress for bgp_stop()
```
bgpd/bgp_fsm.c:1360:29: warning: conflicting types for ‘bgp_stop’ due to enum/integer mismatch; have ‘enum bgp_fsm_state_progress(struct peer *)’ [-Wenum-int-mismatch]
1360 | enum bgp_fsm_state_progress bgp_stop(struct peer *peer)
| ^~~~~~~~
In file included from bgpd/bgp_fsm.c:29:
./bgpd/bgp_fsm.h:111:12: note: previous declaration of ‘bgp_stop’ with type ‘int(struct peer *)’
111 | extern int bgp_stop(struct peer *peer);
| ^~~~~~~~
```
Acee [Tue, 28 May 2024 14:02:27 +0000 (10:02 -0400)]
ospf6d: OSPFv3 route change comparision fixed for ASBR-only change
When a router route already exists in the area border routers table
as an ABR and it solely changes its ABR or ASBR status, the change
was missed and border route is not updated. This fixes the comparison
for the router_bits in the ospf6_path structure.
This fixes issue https://github.com/FRRouting/frr/issues/16053 although
the actual problem is not the computing router (r2) and not the OSPFv3
redistribution (r3).
Iggy Frankovic discovered another ospfd crash when performing fuzzing of OSPF
LSA packets. The crash occurs in ospf_te_parse_ri() function when attemping to
read Segment Routing subTLVs. The original code doesn't check if the size of
the SR subTLVs have the correct length. In presence of erronous LSA, this will
cause a buffer overflow and ospfd crash.
This patch introduces new verification of the subTLVs size for Router
Information TLV.
Iggy Frankovic discovered another ospfd crash when performing fuzzing of OSPF
LSA packets. The crash occurs in ospf_te_parse_ext_link() function when
attemping to read Segment Routing Adjacency SID subTLVs. The original code
doesn't check if the size of the Extended Link TLVs and subTLVs have the correct
length. In presence of erronous LSA, this will cause a buffer overflow and ospfd
crashes.
This patch introduces new verification of the subTLVs size for Extended Link
TLVs and subTLVs. Similar check has been also introduced for the Extended
Prefix TLV.
During fuzzing, Iggy Frankovic discovered that get_edge() function in ospf_te.c
could return null pointer, in particular when the link_id or advertised router
IP addresses are fuzzed. As the null pointer returned by get_edge() function is
not handlei by calling functions, this could cause ospfd crash.
This patch introduces new verification of returned pointer by get_edge()
function and stop the processing in case of null pointer. In addition, link ID
and advertiser router ID are validated before calling ls_find_edge_by_key() to
avoid the creation of a new edge with an invalid key.
Louis Scalbert [Thu, 16 May 2024 14:44:03 +0000 (16:44 +0200)]
isisd: fix heap-after-free with prefix sid
> ==2334217==ERROR: AddressSanitizer: heap-use-after-free on address 0x61000001d0a0 at pc 0x563828c8de6f bp 0x7fffbdaee560 sp 0x7fffbdaee558
> READ of size 1 at 0x61000001d0a0 thread T0
> #0 0x563828c8de6e in prefix_sid_cmp isisd/isis_spf.c:187
> #1 0x7f84b8204f71 in hash_get lib/hash.c:142
> #2 0x7f84b82055ec in hash_lookup lib/hash.c:184
> #3 0x563828c8e185 in isis_spf_prefix_sid_lookup isisd/isis_spf.c:209
> #4 0x563828c90642 in isis_spf_add2tent isisd/isis_spf.c:598
> #5 0x563828c91cd0 in process_N isisd/isis_spf.c:824
> #6 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041
> #7 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821
> #8 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983
> #9 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009
> #10 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090
> #11 0x7f84b835c72d in event_call lib/event.c:2011
> #12 0x7f84b8236d93 in frr_run lib/libfrr.c:1217
> #13 0x563828c21918 in main isisd/isis_main.c:346
> #14 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308
> #15 0x563828c20df9 in _start (/usr/lib/frr/isisd+0xf5df9)
>
> 0x61000001d0a0 is located 96 bytes inside of 184-byte region [0x61000001d040,0x61000001d0f8)
> freed by thread T0 here:
> #0 0x7f84b88a9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123
> #1 0x7f84b8263bae in qfree lib/memory.c:130
> #2 0x563828c8e433 in isis_vertex_del isisd/isis_spf.c:249
> #3 0x563828c91c95 in process_N isisd/isis_spf.c:811
> #4 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041
> #5 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821
> #6 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983
> #7 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009
> #8 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090
> #9 0x7f84b835c72d in event_call lib/event.c:2011
> #10 0x7f84b8236d93 in frr_run lib/libfrr.c:1217
> #11 0x563828c21918 in main isisd/isis_main.c:346
> #12 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308
>
> previously allocated by thread T0 here:
> #0 0x7f84b88aa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> #1 0x7f84b8263a6c in qcalloc lib/memory.c:105
> #2 0x563828c8e262 in isis_vertex_new isisd/isis_spf.c:225
> #3 0x563828c904db in isis_spf_add2tent isisd/isis_spf.c:588
> #4 0x563828c91cd0 in process_N isisd/isis_spf.c:824
> #5 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041
> #6 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821
> #7 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983
> #8 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009
> #9 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090
> #10 0x7f84b835c72d in event_call lib/event.c:2011
> #11 0x7f84b8236d93 in frr_run lib/libfrr.c:1217
> #12 0x563828c21918 in main isisd/isis_main.c:346
> #13 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308
>
> SUMMARY: AddressSanitizer: heap-use-after-free isisd/isis_spf.c:187 in prefix_sid_cmp
> Shadow bytes around the buggy address:
> 0x0c207fffb9c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 0x0c207fffb9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
> 0x0c207fffb9e0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 0x0c207fffb9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
> 0x0c207fffba00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
> =>0x0c207fffba10: fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd fa
> 0x0c207fffba20: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 0x0c207fffba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
> 0x0c207fffba40: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 0x0c207fffba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
> 0x0c207fffba60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user: f7
> Container overflow: fc
> Array cookie: ac
> Intra object redzone: bb
> ASan internal: fe
> Left alloca redzone: ca
> Right alloca redzone: cb
> Shadow gap: cc
> ==2334217==ABORTING
Fixes: 2f7cc7bcd3 ("isisd: detect Prefix-SID collisions and handle them appropriately") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit e697de58431474cdb06eff79bcbc70de4215e222)
zebra: Deny the routes if ip protocol CLI refers to an undefined rmap
Currently zebra does not deny the routes if `ip protocol <proto> route-map
FOO`
commmand is configured with reference to an undefined route-map (FOO in
this case).
However, on FRR restart, in zebra_route_map_check() routes get denied
if route-map name is available but the route-map is not defined. This
change was introduced in fd303a4ba14c762550db972317e1e88528768005.
Fix:
When `ip protocol <proto> route-map FOO` CLI is configured with reference to an
undefined route-map FOO, let the processing in ip_protocol_rm_add() and
ip_protocol_rm_del() go through so that zebra can deny the routes instead
of simply returning. This will result in consistent behavior.
Testing Done:
Before fix:
```
spine-1# configure
spine-1(config)# ip protocol bgp route-map rmap7
spine-1(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
Z - FRR,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* 27.0.0.1/32 is directly connected, lo, 02:27:45
B>* 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1, weight 1, 02:27:35
B>* 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2, weight 1, 02:27:40
B>* 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3, weight 1, 02:27:40
B>* 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4, weight 1, 02:27:40
```
After fix:
```
spine-1(config)# ip protocol bgp route-map route-map67
spine-1(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
Z - FRR,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* 27.0.0.1/32 is directly connected, lo, 00:35:03
B 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1 inactive, weight 1, 00:34:58
B 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2 inactive, weight 1, 00:34:57
B 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3 inactive, weight 1, 00:34:57
B 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4 inactive, weight 1, 00:34:58
spine-1(config)#
root@spine-1:mgmt:/var/home/cumulus# ip route show
root@spine-1:mgmt:/var/home/cumulus#
```
David Lamparter [Mon, 12 Dec 2022 16:50:59 +0000 (17:50 +0100)]
pimd: fix order of operations for evaluating join
join_desired looks at whether up->channel_oil is empty. up->channel_oil
is updated from pim_forward_stop(), calling pim_channel_del_oif(). But
that was being called *after* updating join_desired, so join_desired saw
a non-empty OIL. Pull up the pim_forward_stop() call to before updating
join_desired.
David Lamparter [Mon, 17 Apr 2023 09:47:08 +0000 (11:47 +0200)]
pimd: fix null register before aging out reg-stop
It looks like the code was trying to do this with the null_register
parameter on pim_upstream_start_register_stop_timer(), but that didn't
quite work right. Restructure a bit to get it right.
pimd crashs while unconfigure of rp ka timer as we are trying to access
a yand dnode(suppress timer) which does not exist at the moment.
User just configured rp keepalive timer and not suppress timer,
the yang dnode would not be present. Instead of directly accessing
yang_dnode_get_unit16, first check the yang node exist using
the xpath.
Before:
------
tor-11(config)# no ip pim rp keep-alive-timer 3000
vtysh: error reading from pimd: Success (0)Warning: closing connection to pimd because of an I/O error!
Broadcast message from root@tor-11 (somewhere) (Mon Apr 22 17:29:12 2024):
cumulus-core: Running cl-support for core files "pimd.25467.1713806952.core"
After:
-----
tor-11(config)# no ip pim rp keep-alive-timer 3000
tor-11(config)#
Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
(cherry picked from commit 0c4b7c1f1f359c1d7647fea34f62378af8b640a5)
Donald Sharp [Fri, 19 Apr 2024 16:13:32 +0000 (12:13 -0400)]
lib, zebra: Check for not being a blackhole route
In zebra_interface_nhg_reinstall zebra is checking that the
nhg is a singleton and not a blackhole nhg. This was originally
done with checking that the nexthop is a NEXTHOP_TYPE_IFINDEX,
NEXTHOP_TYPE_IPV4_IFINDEX and NEXTHOP_TYPE_IPV6_IFINDEX. This
was excluding NEXTHOP_TYPE_IPV4 and NEXTHOP_TYPE_IPV6. These
were both possible to be received and maintained from the upper
level protocol for when a route is being recursively resolved.
If we have gotten to this point in zebra_interface_nhg_reinstall
the nexthop group has already been installed at least once
and we *know* that it is actually a valid nexthop. What the
test is really trying to do is ensure that we are not reinstalling
a blackhole nexthop group( Which is not possible to even be
here by the way, but safety first! ). So let's change
to test for that instead.
Donatas Abraitis [Wed, 27 Mar 2024 17:08:38 +0000 (19:08 +0200)]
bgpd: Prevent from one more CVE triggering this place
If we receive an attribute that is handled by bgp_attr_malformed(), use
treat-as-withdraw behavior for unknown (or missing to add - if new) attributes.
Donatas Abraitis [Wed, 27 Mar 2024 16:42:56 +0000 (18:42 +0200)]
bgpd: Fix error handling when receiving BGP Prefix SID attribute
Without this patch, we always set the BGP Prefix SID attribute flag without
checking if it's malformed or not. RFC8669 says that this attribute MUST be discarded.
Also, this fixes the bgpd crash when a malformed Prefix SID attribute is received,
with malformed transitive flags and/or TLVs.
Donald Sharp [Sat, 2 Mar 2024 14:50:38 +0000 (09:50 -0500)]
bgpd: Ensure community data is freed in some cases.
Customer has this valgrind trace:
Direct leak of 2829120 byte(s) in 70728 object(s) allocated from:
0 in community_new ../bgpd/bgp_community.c:39
1 in community_uniq_sort ../bgpd/bgp_community.c:170
2 in route_set_community ../bgpd/bgp_routemap.c:2342
3 in route_map_apply_ext ../lib/routemap.c:2673
4 in subgroup_announce_check ../bgpd/bgp_route.c:2367
5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914
6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199
7 in hash_walk ../lib/hash.c:285
8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061
9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059
10 in bgp_process_main_one ../bgpd/bgp_route.c:3221
11 in bgp_process_wq ../bgpd/bgp_route.c:3221
12 in work_queue_run ../lib/workqueue.c:282
The above leak detected by valgrind was from a screenshot so I copied it
by hand. Any mistakes in line numbers are purely from my transcription.
Additionally this is against a slightly modified 8.5.1 version of FRR.
Code inspection of 8.5.1 -vs- latest master shows the same problem
exists. Code should be able to be followed from there to here.
What is happening:
There is a route-map being applied that modifes the outgoing community
to a peer. This is saved in the attr copy created in
subgroup_process_announce_selected. This community pointer is not
interned. So the community->refcount is still 0. Normally when
a prefix is announced, the attr and the prefix are placed on a
adjency out structure where the attribute is interned. This will
cause the community to be saved in the community hash list as well.
In a non-normal operation when the decision to send is aborted after
the route-map application, the attribute is just dropped and the
pointer to the community is just dropped too, leading to situations
where the memory is leaked. The usage of bgp suppress-fib would
would be a case where the community is caused to be leaked.
Additionally the previous commit where an unsuppress-map is used
to modify the outgoing attribute but since unsuppress-map was
not considered part of outgoing policy the attribute would be dropped as
well. This pointer drop also extends to any dynamically allocated
memory saved by the attribute pointer that was not interned yet as well.
So let's modify the return case where the decision is made to
not send the prefix to the peer to always just flush the attribute
to ensure memory is not leaked.
Fixes: #15459 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Wed, 13 Mar 2024 14:26:58 +0000 (10:26 -0400)]
bgpd: Ensure that the correct aspath is free'd
Currently in subgroup_default_originate the attr.aspath
is set in bgp_attr_default_set, which hashs the aspath
and creates a refcount for it. If this is a withdraw
the subgroup_announce_check and bgp_adj_out_set_subgroup
is called which will intern the attribute. This will
cause the the attr.aspath to be set to a new value
finally at the bottom of the function it intentionally
uninterns the aspath which is not the one that was
created for this function. This reduces the other
aspath's refcount by 1 and if a clear bgp * is issued
fast enough the aspath for that will be removed
and the system will crash.
Louis Scalbert [Tue, 20 Feb 2024 16:49:01 +0000 (17:49 +0100)]
zebra: fix crash if macvlan link in another netns
A macvlan interface can have its underlying link-interface in another
namespace (aka. netns). However, by default, zebra does not know the
interface from the other namespaces. It results in a crash the pointer
to the link interface is NULL.
Fix the crash by returning when the macvlan link-interface is in another
namespace. No need to go further because any vxlan under the macvlan
interface would not be accessible by zebra.
zebra: fix nhg out of sync between zebra and kernel
PR#13413 introduces reinstall mechanism, but there is problem with the route
leak scenario.
With route leak configuration: ( `x1` and `x2` are binded to `vrf1` )
```
vrf vrf2
ip route 75.75.75.75/32 77.75.1.75 nexthop-vrf vrf1
ip route 75.75.75.75/32 77.75.2.75 nexthop-vrf vrf1
exit-vrf
```
Firstly, all are ok. But after `x1` is set down and up ( The interval
between the down and up operations should be less than 180 seconds. ) ,
`x1` is lost from the nexthop group:
```
anlan# ip nexthop
id 121 group 122/123 proto zebra
id 122 via 77.75.1.75 dev x1 scope link proto zebra
id 123 via 77.75.2.75 dev x2 scope link proto zebra
anlan# ip route show table 2
75.75.75.75 nhid 121 proto 196 metric 20
nexthop via 77.75.1.75 dev x1 weight 1
nexthop via 77.75.2.75 dev x2 weight 1
anlan# ip link set dev x1 down
anlan# ip link set dev x1 up
anlan# ip route show table 2 <- Wrong, one nexthop lost from group
75.75.75.75 nhid 121 via 77.75.2.75 dev x2 proto 196 metric 20
anlan# ip nexthop
id 121 group 123 proto zebra
id 122 via 77.75.1.75 dev x1 scope link proto zebra
id 123 via 77.75.2.75 dev x2 scope link proto zebra
anlan# show ip route vrf vrf2 <- Still ok
VRF vrf2:
S>* 75.75.75.75/32 [1/0] via 77.75.1.75, x1 (vrf vrf1), weight 1, 00:00:05
* via 77.75.2.75, x2 (vrf vrf1), weight 1, 00:00:05
```
From the impact on kernel:
The `nh->type` of `id 122` is *always* `NEXTHOP_TYPE_IPV4` in the route leak
case. Then, `nexthop_is_ifindex_type()` introduced by commit `5bb877` always
returns `false`, so its dependents can't be reinstalled. After `x1` is down,
there is only `id 123` in the group of `id 121`. So, Finally `id 121` remains
unchanged after `x1` is up, i.e., `id 122` is not added to the group even it is
reinstalled itself.
From the impact on zebra:
The `show ip route vrf vrf2` is still ok because the `id`s are reused/reinstalled
successfully within 180 seconds after `x1` is down and up. The group of `id 121`
is with old `NEXTHOP_GROUP_INSTALLED` flag, and it is still the group of `id 122`
and `id 123` as before.
In this way, kernel and zebra have become out of sync.
The `nh->type` of `id 122` should be adjusted to `NEXTHOP_TYPE_IPV4_IFINDEX`
after nexthop resolved. This commit is for doing this to make that reinstall
mechanism work.
Intermittently zebra and kernel are out of sync
when interface flaps and the add's/dels are in
same processing queue and zebra assumes no change in nexthop.
Hence we need to bring in a reinstall to kernel
of the nexthops and routes to sync their states.
Upon interface flap kernel would have deleted NHGs
associated to a interface (the one flapped),
zebra retains NHGs for 3 mins even though upper
layer protocol removes the nexthops (associated NHG).
As part of interface address add ,
re-add singleton NHGs associated to interface.
pimd: re-evaluated S,G OILs upon RP changes and for empty SG upstream oils
Topology:
TOR11 (FHR) --- LEAF-11---SPINE1 (RP)MSDP SPINE-2(RP)MSDP --- LEAF-12 -- TOR12 (LHR)
| | | | |
| -----------------------------------------------------(ECMP) |
| | | |
-----------------------------------------------------------------------(ECMP)
Issue:
In some triggers, S,G upstream is preserved even with the PP timer expiry, resulting
in S,G with NULL OILS. This could be because we create a dummy S,G upstream and
dummy channel_oif for *,G, where RPF is UNKNOWN. As a result, PIM+VXLAN traffic is never
forwarded downstream to LHR.
Fix:
when the S,G stream is running, Determine if a reevaluation of the outgoing interface
list (OIL) is required. S,G upstream should then inherit the OIL from *,G.
David Lamparter [Thu, 16 Mar 2023 10:00:02 +0000 (11:00 +0100)]
bgpd: fix NULL argument warning
gcc 12.2.0 complains `error: ‘%s’ directive argument is null`, even
though all enum values are covered with a string. Let's just go with a
`???` default.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Issue:
Previously, the PBR common was updated for every rule update or deletion
example:
let say we have three rule 11, 12, 13 and if we are removing rule 12. in the current code
we are making the entire map "valid" to false.
pbr-map MAP1 seq 11
match src-ip 90.1.1.2/32
set nexthop 20.1.1.2 swp1
pbr-map MAP1 seq 12
match src-ip 90.1.1.3/32
set nexthop 20.1.1.2 swp1
pbr-map MAP1 seq 13
match src-ip 90.1.1.4/32
set nexthop 20.1.1.2 swp1
no pbr-map MAP1 seq 12 ==> turns whole map valid to false.
r1(config)# end
r1# show pbr map
pbr-map MAP1 valid: no
Seq: 11 rule: 310
Installed: yes Reason: Valid
SRC IP Match: 90.1.1.2/32
nexthop 20.1.1.2 swp1
Installed: yes Tableid: 10002
Seq: 13 rule: 312
Installed: yes Reason: Valid
SRC IP Match: 90.1.1.4/32
nexthop 20.1.1.2 swp1
Installed: yes Tableid: 10004
Fix:
Now, the PBR common will only be updated when the last rule is being deleted.
This change ensures that we only send a delete request to Zebra once, and only
set the valid and installed flags to false when the last rule is deleted.
This optimizes the handling of PBR rules and reduces unnecessary interactions with Zebra
Igor Ryzhov [Tue, 23 Jan 2024 00:32:22 +0000 (02:32 +0200)]
pimd: fix crash when configuring ssmpingd
Command: `ip ssmpingd 1.1.1.1`
Backtrace:
```
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0x00007fd1d3b02859 in __GI_abort () at abort.c:79
0x00007fd1d3e323e1 in yang_dnode_xpath_get_canon (dnode=<optimized out>, xpath_fmt=<optimized out>, ap=<optimized out>) at lib/yang_wrappers.c:61
0x00007fd1d3e34f41 in yang_dnode_get_ipv4 (addr=addr@entry=0x7ffc368554d4, dnode=<optimized out>, xpath_fmt=xpath_fmt@entry=0x5556af8680d4 "./source-addr") at lib/yang_wrappers.c:826
0x00005556af8216d3 in routing_control_plane_protocols_control_plane_protocol_pim_address_family_ssm_pingd_source_ip_create (args=0x7ffc36855530) at pimd/pim_nb_config.c:925
0x00007fd1d3dec13f in nb_callback_create (nb_node=0x5556b197ea40, nb_node=0x5556b197ea40, errmsg_len=8192, errmsg=0x7ffc36855a90 "", resource=0x5556b18fa6f8, dnode=0x5556b1ad7a10, event=NB_EV_APPLY, context=0x5556b1ad75c0) at lib/northbound.c:1260
nb_callback_configuration (context=0x5556b1ad75c0, event=NB_EV_APPLY, change=<optimized out>, errmsg=0x7ffc36855a90 "", errmsg_len=8192) at lib/northbound.c:1648
0x00007fd1d3deca6c in nb_transaction_process (event=event@entry=NB_EV_APPLY, transaction=transaction@entry=0x5556b1ad75c0, errmsg=errmsg@entry=0x7ffc36855a90 "", errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:1779
0x00007fd1d3decdd6 in nb_candidate_commit_apply (transaction=0x5556b1ad75c0, save_transaction=save_transaction@entry=true, transaction_id=transaction_id@entry=0x0, errmsg=errmsg@entry=0x7ffc36855a90 "", errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:1129
0x00007fd1d3decf15 in nb_candidate_commit (context=..., candidate=<optimized out>, save_transaction=save_transaction@entry=true, comment=comment@entry=0x0, transaction_id=transaction_id@entry=0x0, errmsg=0x7ffc36855a90 "", errmsg_len=8192) at lib/northbound.c:1162
0x00007fd1d3ded4af in nb_cli_classic_commit (vty=vty@entry=0x5556b1ada2a0) at lib/northbound_cli.c:50
0x00007fd1d3df025f in nb_cli_apply_changes_internal (vty=vty@entry=0x5556b1ada2a0, xpath_base=xpath_base@entry=0x7ffc36859b50 ".", clear_pending=clear_pending@entry=false) at lib/northbound_cli.c:177
0x00007fd1d3df06ad in nb_cli_apply_changes (vty=vty@entry=0x5556b1ada2a0, xpath_base_fmt=xpath_base_fmt@entry=0x0) at lib/northbound_cli.c:233
0x00005556af80fdd5 in pim_process_ssmpingd_cmd (vty=0x5556b1ada2a0, operation=NB_OP_CREATE, src_str=0x5556b1ad9630 "1.1.1.1") at pimd/pim_cmd_common.c:3423
0x00007fd1d3da7b0e in cmd_execute_command_real (vline=vline@entry=0x5556b1ac9520, vty=vty@entry=0x5556b1ada2a0, cmd=cmd@entry=0x0, up_level=up_level@entry=0) at lib/command.c:982
0x00007fd1d3da7cb1 in cmd_execute_command (vline=vline@entry=0x5556b1ac9520, vty=vty@entry=0x5556b1ada2a0, cmd=0x0, vtysh=vtysh@entry=0) at lib/command.c:1040
0x00007fd1d3da7e50 in cmd_execute (vty=vty@entry=0x5556b1ada2a0, cmd=cmd@entry=0x5556b1ae0a30 "ip ssmpingd 1.1.1.1", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1207
0x00007fd1d3e278be in vty_command (vty=vty@entry=0x5556b1ada2a0, buf=<optimized out>) at lib/vty.c:591
0x00007fd1d3e27afd in vty_execute (vty=0x5556b1ada2a0) at lib/vty.c:1354
0x00007fd1d3e2bb23 in vtysh_read (thread=<optimized out>) at lib/vty.c:2362
0x00007fd1d3e22254 in event_call (thread=thread@entry=0x7ffc3685cd80) at lib/event.c:2003
0x00007fd1d3dce9e8 in frr_run (master=0x5556b183c830) at lib/libfrr.c:1218
0x00005556af803653 in main (argc=6, argv=<optimized out>, envp=<optimized out>) at pimd/pim_main.c:162
```
Donald Sharp [Mon, 11 Dec 2023 15:46:53 +0000 (10:46 -0500)]
bgpd: Make `suppress-fib-pending` clear peering
When a peer has come up and already started installing
routes into the rib and `suppress-fib-pending` is either
turned on or off. BGP is left with some routes that
may need to be withdrawn from peers and routes that
it does not know the status of. Clear the BGP peers
for the interesting parties and let's let us come
up to speed as needed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
bgpd
Check mandatory attributes more carefully for the UPDATE message
Do not suppress conditional advertisement updates if triggered
Fix crash in SNMP BGP4V2-MIB bgpv2PeerErrorsTable()
Handle MP_UNREACH_NLRI malformed packets with session reset
Ignore handling NLRIs if we received the MP_UNREACH_NLRI attribute
Initialise timebuf arrays to zeros for dampening reuse timer
Initialise buffer in bgp_notify_admin_message() before using it
Make sure dampening is enabled for the specified AFI/SAFI
Use proper AFI when dumping information for dampening stuff
Treat EOR as withdrawn to avoid unwanted handling of malformed attrs
eigrpd
Use the correct memory pool on interface deletion
vtysh
Fix show route map JSON output
ospfd
Fix infinite loop when listing OSPF interfaces
pbrd
Fix show pbr map detail json output
zebra
Add encap type when building packet for FPM
Display ptmStatus order in interface JSON
Fix connected route deletion when multiple entry exists
Fix FPM multipath encap addition
Fix link update for veth interfaces
Fix zebra crash when replacing nhe during shutdown
Prevent null pointer dereference
Donatas Abraitis [Sun, 29 Oct 2023 20:44:45 +0000 (22:44 +0200)]
bgpd: Ignore handling NLRIs if we received MP_UNREACH_NLRI
If we receive MP_UNREACH_NLRI, we should stop handling remaining NLRIs if
no mandatory path attributes received.
In other words, if MP_UNREACH_NLRI received, the remaining NLRIs should be handled
as a new data, but without mandatory attributes, it's a malformed packet.
In normal case, this MUST not happen at all, but to avoid crashing bgpd, we MUST
handle that.
Donatas Abraitis [Fri, 27 Oct 2023 08:56:45 +0000 (11:56 +0300)]
bgpd: Treat EOR as withdrawn to avoid unwanted handling of malformed attrs
Treat-as-withdraw, otherwise if we just ignore it, we will pass it to be
processed as a normal UPDATE without mandatory attributes, that could lead
to harmful behavior. In this case, a crash for route-maps with the configuration
such as:
Donald Sharp [Fri, 17 Nov 2023 21:57:20 +0000 (16:57 -0500)]
zebra: Fix fpm multipath encap addition
The fpm code path in building a ecmp route for evpn has
a bug that caused it to not add the encap attribute to
the netlink message. See #f0f7b285b99dbd971400d33feea007232c0bd4a9
for the single path case being fixed.
Donald Sharp [Sat, 28 Oct 2023 14:03:39 +0000 (10:03 -0400)]
zebra: Add encap type when building packet for FPM
Currently in the single nexthop case w/ evpn sending
down via the FPM the encap type is not being set
for the nexthop.
This looks like the result of some code reorg for the
nexthop happened but the fpm failed to be accounted for.
Let's just move the encap type encoding to where it
will happen.
'detail' and 'josn' keyword is given as an optional parameter
for cli arguments. Hence 'detail' keyword was consider as a
pbr 'name' for "show pbr map detail json" command.
Donatas Abraitis [Mon, 23 Oct 2023 20:34:10 +0000 (23:34 +0300)]
bgpd: Check mandatory attributes more carefully for UPDATE message
If we send a crafted BGP UPDATE message without mandatory attributes, we do
not check if the length of the path attributes is zero or not. We only check
if attr->flag is at least set or not. Imagine we send only unknown transit
attribute, then attr->flag is always 0. Also, this is true only if graceful-restart
capability is received.
Thread 1 "bgpd" received signal SIGSEGV, Segmentation fault.
0x00005555556e37be in route_set_aspath_prepend (rule=0x555555aac0d0, prefix=0x7fffffffe050,
object=0x7fffffffdb00) at bgpd/bgp_routemap.c:2282
2282 if (path->attr->aspath->refcnt)
(gdb)
```
Donatas Abraitis [Fri, 20 Oct 2023 08:59:59 +0000 (11:59 +0300)]
bgpd: Do not suppress conditional advertisement updates if triggered
If we have a prefix-list with one entry, and after some time we append a prefix-list
with some more additional entries, conditional advertisement is triggered, and the
old entries are suppressed (because they look identical as sent before).
Hence, the old entries are sent as withdrawals and only new entries sent as updates.
Force re-sending all BGP updates for conditional advertisement. The same is done
for route-refresh, and/or soft clear operations.
projects / mirror / frr.git / log