]> git.puffer.fish Git - matthieu/frr.git/log
matthieu/frr.git
7 months agoFRR Release 8.4.6 rc/8.4.6 docker/8.4.6 frr-8.4.6
Donatas Abraitis [Fri, 13 Sep 2024 19:21:40 +0000 (22:21 +0300)]
FRR Release 8.4.6

- bgpd
-    Fix for CVE-2024-44070
-    Fix crash at no rpki
- isisd
-    Fix update link params after circuit is up
- tools
-    Ignore errors for frr reload stuff

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
7 months agoMerge pull request #16817 from opensourcerouting/fix/backports_for_8.4
Donald Sharp [Fri, 13 Sep 2024 15:27:03 +0000 (11:27 -0400)]
Merge pull request #16817 from opensourcerouting/fix/backports_for_8.4

Manual backport for 8.4

7 months agobgpd: Check the actual remaining stream length before taking TLV value
Donatas Abraitis [Wed, 31 Jul 2024 05:35:14 +0000 (08:35 +0300)]
bgpd: Check the actual remaining stream length before taking TLV value

```
    0 0xb50b9f898028 in __sanitizer_print_stack_trace (/home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/.libs/bgpd+0x368028) (BuildId: 3292703ed7958b20076550c967f879db8dc27ca7)
    1 0xb50b9f7ed8e4 in fuzzer::PrintStackTrace() (/home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/.libs/bgpd+0x2bd8e4) (BuildId: 3292703ed7958b20076550c967f879db8dc27ca7)
    2 0xb50b9f7d4d9c in fuzzer::Fuzzer::CrashCallback() (/home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/.libs/bgpd+0x2a4d9c) (BuildId: 3292703ed7958b20076550c967f879db8dc27ca7)
    3 0xe0d12d7469cc  (linux-vdso.so.1+0x9cc) (BuildId: 1a77697e9d723fe22246cfd7641b140c427b7e11)
    4 0xe0d12c88f1fc in __pthread_kill_implementation nptl/pthread_kill.c:43:17
    5 0xe0d12c84a678 in gsignal signal/../sysdeps/posix/raise.c:26:13
    6 0xe0d12c83712c in abort stdlib/abort.c:79:7
    7 0xe0d12d214724 in _zlog_assert_failed /home/ubuntu/frr-public/frr_public_private-libfuzzer/lib/zlog.c:789:2
    8 0xe0d12d1285e4 in stream_get /home/ubuntu/frr-public/frr_public_private-libfuzzer/lib/stream.c:324:3
    9 0xb50b9f8e47c4 in bgp_attr_encap /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_attr.c:2758:3
    10 0xb50b9f8dcd38 in bgp_attr_parse /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_attr.c:3783:10
    11 0xb50b9faf74b4 in bgp_update_receive /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:2383:20
    12 0xb50b9faf1dcc in bgp_process_packet /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:4075:11
    13 0xb50b9f8c90d0 in LLVMFuzzerTestOneInput /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_main.c:582:3
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
7 months agobgpd: fix crash at no rpki
Louis Scalbert [Tue, 20 Aug 2024 08:33:30 +0000 (10:33 +0200)]
bgpd: fix crash at no rpki

When 'no rpki' is requested and the rtrlib RPKI object was freed, bgpd
is crashing.

RPKI is configured in VRF red.

> ip l set red down
> ip l del red
> printf 'conf\n vrf red\n no rpki' | vtysh

> Core was generated by `/usr/bin/bgpd -A 127.0.0.1 -M snmp -M rpki -M bmp'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:44
> 44 ./nptl/pthread_kill.c: No such file or directory.
> [Current thread is 1 (Thread 0x7fb401f419c0 (LWP 190226))]
> (gdb) bt
> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=140411103615424, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3  0x00007fb4021ad476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x00007fb4025ce22b in core_handler (signo=11, siginfo=0x7fff831b2d70, context=0x7fff831b2c40) at lib/sigevent.c:248
> #5  <signal handler called>
> #6  rtr_mgr_remove_group (config=0x55fe8789f750, preference=11) at /build/make-pkg/output/source/DIST_RTRLIB/rtrlib/rtrlib/rtr_mgr.c:607
> #7  0x00007fb40145f518 in rpki_delete_all_cache_nodes (rpki_vrf=0x55fe8789f4f0) at bgpd/bgp_rpki.c:442
> #8  0x00007fb401463098 in no_rpki_magic (self=0x7fb40146bba0 <no_rpki_cmd>, vty=0x55fe877f5130, argc=2, argv=0x55fe877fccd0) at bgpd/bgp_rpki.c:1732
> #9  0x00007fb40145c09a in no_rpki (self=0x7fb40146bba0 <no_rpki_cmd>, vty=0x55fe877f5130, argc=2, argv=0x55fe877fccd0) at ./bgpd/bgp_rpki_clippy.c:37
> #10 0x00007fb402527abc in cmd_execute_command_real (vline=0x55fe877fd150, vty=0x55fe877f5130, cmd=0x0, up_level=0) at lib/command.c:984
> #11 0x00007fb402527c35 in cmd_execute_command (vline=0x55fe877fd150, vty=0x55fe877f5130, cmd=0x0, vtysh=0) at lib/command.c:1043
> #12 0x00007fb4025281e5 in cmd_execute (vty=0x55fe877f5130, cmd=0x55fe877fb8c0 "no rpki\n", matched=0x0, vtysh=0) at lib/command.c:1209
> #13 0x00007fb4025f0aed in vty_command (vty=0x55fe877f5130, buf=0x55fe877fb8c0 "no rpki\n") at lib/vty.c:615
> #14 0x00007fb4025f2a11 in vty_execute (vty=0x55fe877f5130) at lib/vty.c:1378
> #15 0x00007fb4025f513d in vtysh_read (thread=0x7fff831b5fa0) at lib/vty.c:2373
> #16 0x00007fb4025e9611 in event_call (thread=0x7fff831b5fa0) at lib/event.c:2011
> #17 0x00007fb402566976 in frr_run (master=0x55fe871a14a0) at lib/libfrr.c:1212
> #18 0x000055fe857829fa in main (argc=9, argv=0x7fff831b6218) at bgpd/bgp_main.c:549

Fixes: 8156765abe ("bgpd: Add `no rpki` command")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
7 months agoisisd: fix update link params after circuit is up
Louis Scalbert [Tue, 27 Aug 2024 16:22:27 +0000 (18:22 +0200)]
isisd: fix update link params after circuit is up

If the link-params are set when the circuit not yet up, the link-params
are never updated.

isis_link_params_update() is called from isis_circuit_up() but returns
immediately because circuit->state != C_STATE_UP. circuit->state is
updated in isis_csm_state_change after isis_circuit_up().

> struct isis_circuit *isis_csm_state_change(enum isis_circuit_event event,
>     struct isis_circuit *circuit,
>     void *arg)
> {
> [...]
>  if (isis_circuit_up(circuit) != ISIS_OK) {
>  isis_circuit_deconfigure(circuit, area);
>  break;
>  }
>  circuit->state = C_STATE_UP;
>  isis_event_circuit_state_change(circuit, circuit->area,
>  1);

Do not return isis_link_params_update() if circuit->state != C_STATE_UP.

Fixes: 0fdd8b2b11 ("isisd: update link params after circuit is up")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
9 months agoMerge pull request #16468 from opensourcerouting/fix/243e27abccf8d02caabc6ae1ea758c4b...
Donald Sharp [Thu, 25 Jul 2024 11:45:36 +0000 (07:45 -0400)]
Merge pull request #16468 from opensourcerouting/fix/243e27abccf8d02caabc6ae1ea758c4bdc3069e2_8.4

tools: Ignore errors for frr reload stuff

9 months agotools: Ignore errors for frr reload stuff
Donatas Abraitis [Fri, 30 Jun 2023 09:58:32 +0000 (12:58 +0300)]
tools: Ignore errors for frr reload stuff

When we pass an unknown/wrong command and do `systemctl reload frr`, all processes
are killed, and not started up.

Like doing with frr-reload.py, all good:

```
$ /usr/lib/frr/frr-reload.py --reload /etc/frr/frr.conf
vtysh failed to process new configuration: vtysh (mark file) exited with status 2:
b'line 20: % Unknown command:  neighbor 192.168.10.123 bfd 300 300\n\n'
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
10 months agoFRR Release 8.4.5 rc/8.4 docker/8.4.5 frr-8.4.5
Jafar Al-Gharaibeh [Thu, 6 Jun 2024 15:54:56 +0000 (10:54 -0500)]
FRR Release 8.4.5

Changelog:

babeld
    Fix #11808 to avoid infinite loops

bgpd
    Check mandatory attributes more carefully for update message
    Do not explicitly print maxttl value for ebgp-multihop vty output
    Do not process nlris if the attribute length is zero
    Don't read the first byte of orf header if we are ahead of stream
    Ensure community data is freed in some cases.
    Ensure that the correct aspath is free'd
    Evpn code was not properly unlocking rd_dest
    Fix error handling when receiving bgp prefix sid attribute
    Fix null argument warning
    Fix session reset issue caused by malformed core attributes
    Fix use beyond end of stream of labeled unicast parsing
    Handle mp_reach_nlri malformed packets with session reset
    Ignore handling nlris if we received mp_unreach_nlri
    Include unsuppress-map as a valid outgoing policy
    Prevent from one more cve triggering this place
    Treat eor as withdrawn to avoid unwanted handling of malformed attrs
    Use enum bgp_create_error_code as argument in header
    Use treat-as-withdraw for tunnel encapsulation attribute

isisd
    Fix heap-after-free with prefix sid
    need to link directly against libyang

lib
    Fix evpn nexthop config order
    Allow unsetting walltime-warning and cpu-warning
    Make cmd_element->attr a bitmask & clarify
    Replace deprecated ares_gethostbyname
    Replace deprecated ares_process()

nhrpd
    Fix nhrp_peer leak
    Fix core dump on shutdown

ospf6d
    Fix crash because neighbor structure was freed
    Fix uninitialized warnings
    Ospfv3 route change comparision fixed for asbr-only change
    Stop crash in ospf6_write
    Prevent heap-buffer-overflow with unknown type

ospfd
    Check for nulls in vty code
    Correct opaque lsa extended parser
    Prevent use after free( and crash of ospf ) when no router ospf
    Protect call to get_edge() in ospf_te.c
    Solved crash in ospf te parsing
    Solved crash in ri parsing with ospf te

pimd
    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

ripd
    Revert "cleanup memory allocations on shutdown"

ripngd
    Revert "cleanup memory allocations on shutdown"

vtysh
    Print uniq lines when parsing `no service ...`

zebra
    Deny the routes if ip protocol cli refers to an undefined rmap
    Fix connected route deletion when multiple entry exists

Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
10 months agoMerge pull request #16174 from Jafaral/nhrp-8.4
Donald Sharp [Thu, 6 Jun 2024 15:02:08 +0000 (11:02 -0400)]
Merge pull request #16174 from Jafaral/nhrp-8.4

[8.4] nhrp: backport fixes #16141 and #16166

10 months agonhrpd: Fix nhrp_peer leak
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

=================================================================
==20265==ERROR: LeakSanitizer: detected memory leaks

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

=================================================================
==20400==ERROR: LeakSanitizer: detected memory leaks

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).
***********************************************************************************
```

Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
10 months agonhrpd: core dump on shutdown backport fix
Dave LeRoy [Fri, 31 May 2024 17:05:10 +0000 (10:05 -0700)]
nhrpd: core dump on shutdown backport fix

This fixes a merge conflict encountered when backporting PR 15879

Signed-off-by: Dave LeRoy <dleroy@labn.net>
10 months agoMerge pull request #16138 from FRRouting/mergify/bp/stable/8.4/pr-16111
Donald Sharp [Sat, 1 Jun 2024 14:03:57 +0000 (10:03 -0400)]
Merge pull request #16138 from FRRouting/mergify/bp/stable/8.4/pr-16111

ospf6d: Prevent heap-buffer-overflow with unknown type (backport #16111)

10 months agoMerge pull request #16129 from FRRouting/mergify/bp/stable/8.4/pr-16115
Jafar Al-Gharaibeh [Sat, 1 Jun 2024 03:46:28 +0000 (22:46 -0500)]
Merge pull request #16129 from FRRouting/mergify/bp/stable/8.4/pr-16115

pimd: fix crash when mixing ssm/any-source joins (backport #16115)

10 months agoospf6d: Prevent heap-buffer-overflow with unknown type
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.

Signed-off-by: Iggy Frankovic <iggy07@gmail.com>
(cherry picked from commit 826f2510e67711045e52cf4b5e3ddef514ed556e)

10 months agopimd: fix crash when mixing ssm/any-source joins
Jafar Al-Gharaibeh [Thu, 30 May 2024 17:46:47 +0000 (12:46 -0500)]
pimd: fix crash when mixing ssm/any-source joins

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.

Fixes: #15630
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
(cherry picked from commit a951960a15e8b6b5ed248abb0ecc9eb4e9a3427f)

11 months agoMerge pull request #16108 from FRRouting/mergify/bp/stable/8.4/pr-16098
Donald Sharp [Wed, 29 May 2024 16:15:53 +0000 (12:15 -0400)]
Merge pull request #16108 from FRRouting/mergify/bp/stable/8.4/pr-16098

ospf6d: OSPFv3 route change comparision fixed for ASBR-only change (backport #16098)

11 months agoospf6d: OSPFv3 route change comparision fixed for ASBR-only change
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).

Signed-off-by: Acee <aceelindem@gmail.com>
(cherry picked from commit 772688d2d3c03d8eeeb711c2fe3735c9e0885498)

11 months agoMerge pull request #16088 from FRRouting/mergify/bp/stable/8.4/pr-15674
Donald Sharp [Sat, 25 May 2024 14:52:12 +0000 (10:52 -0400)]
Merge pull request #16088 from FRRouting/mergify/bp/stable/8.4/pr-15674

ospfd: Solved crash in RI parsing with OSPF TE (backport #15674)

11 months agoospfd: protect call to get_edge() in ospf_te.c
Olivier Dugeon [Tue, 16 Apr 2024 14:42:06 +0000 (16:42 +0200)]
ospfd: protect call to get_edge() in ospf_te.c

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.

CVE-2024-34088

Co-authored-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit 8c177d69e32b91b45bda5fc5da6511fa03dc11ca)

11 months agoospfd: Correct Opaque LSA Extended parser
Olivier Dugeon [Fri, 5 Apr 2024 10:57:11 +0000 (12:57 +0200)]
ospfd: Correct Opaque LSA Extended parser

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.

Co-authored-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit 5557a289acdaeec8cc63ffc97b5c2abf6dee7b3a)

11 months agoospfd: Solved crash in RI parsing with OSPF TE
Olivier Dugeon [Wed, 3 Apr 2024 14:28:23 +0000 (16:28 +0200)]
ospfd: Solved crash in RI parsing with OSPF TE

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.

Co-authored-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit f69d1313b19047d3d83fc2b36a518355b861dfc4)

11 months agoMerge pull request #16081 from FRRouting/mergify/bp/stable/8.4/pr-16021
Donald Sharp [Fri, 24 May 2024 14:29:07 +0000 (10:29 -0400)]
Merge pull request #16081 from FRRouting/mergify/bp/stable/8.4/pr-16021

isisd: fix heap-after-free with prefix sid (backport #16021)

11 months agoisisd: fix heap-after-free with prefix sid
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)

11 months agoMerge pull request #16064 from FRRouting/mergify/bp/stable/8.4/pr-16032
Donald Sharp [Tue, 21 May 2024 18:46:00 +0000 (14:46 -0400)]
Merge pull request #16064 from FRRouting/mergify/bp/stable/8.4/pr-16032

zebra: Deny the routes if ip protocol CLI refers to an undefined rmap (backport #16032)

11 months agozebra: Deny the routes if ip protocol CLI refers to an undefined rmap
Pooja Jagadeesh Doijode [Thu, 16 May 2024 23:36:18 +0000 (16:36 -0700)]
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

root@spine-1:mgmt:/var/home/cumulus# vtysh -c "show run" | grep rmap7
ip protocol bgp route-map rmap7
root@spine-1:mgmt:/var/home/cumulus#

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#
```

Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
(cherry picked from commit 705e8ef78f84dea3af5943a74571f968ad076c8d)

11 months agoMerge pull request #15992 from Jafaral/pim-fixes-8.4
Donatas Abraitis [Mon, 13 May 2024 04:56:39 +0000 (07:56 +0300)]
Merge pull request #15992 from Jafaral/pim-fixes-8.4

pimd: fixes split off from #15969 (backport #15975)

11 months agopimd: fix order of operations for evaluating join
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.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit fdb1a6fed5a8e42447b5b9633ad9df0f3042d0a9)

11 months agopimd: fix null register before aging out reg-stop
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.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit dce38da8061a7ac62c690dbb8a89cae7f9a758d6)

# Conflicts:
# pimd/pim_upstream.c

11 months agopimd: fix dr-priority range
David Lamparter [Fri, 14 Apr 2023 15:17:27 +0000 (17:17 +0200)]
pimd: fix dr-priority range

0 is a valid DR priority.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit b564c1d890aef75067db22df09e608faf72b99f5)

11 months agoMerge pull request #15934 from FRRouting/mergify/bp/stable/8.4/pr-15628
David Lamparter [Mon, 6 May 2024 11:33:18 +0000 (13:33 +0200)]
Merge pull request #15934 from FRRouting/mergify/bp/stable/8.4/pr-15628

CVE-2024-31948

11 months agoMerge pull request #15933 from opensourcerouting/8.4-backport-20240506
David Lamparter [Mon, 6 May 2024 11:32:56 +0000 (13:32 +0200)]
Merge pull request #15933 from opensourcerouting/8.4-backport-20240506

CVE-2023-47234, CVE-2023-47235, and CVE-2024-27913

11 months agobgpd: Prevent from one more CVE triggering this place
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.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit babb23b74855e23c987a63f8256d24e28c044d07)

11 months agobgpd: Fix error handling when receiving BGP Prefix SID attribute
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.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit ba6a8f1a31e1a88df2de69ea46068e8bd9b97138)

11 months agoospfd: Solved crash in OSPF TE parsing
Olivier Dugeon [Mon, 26 Feb 2024 09:40:34 +0000 (10:40 +0100)]
ospfd: Solved crash in OSPF TE parsing

Iggy Frankovic discovered an ospfd crash when perfomring fuzzing of OSPF LSA
packets. The crash occurs in ospf_te_parse_te() function when attemping to
create corresponding egde from TE Link parameters. If there is no local
address, an edge is created but without any attributes. During parsing, the
function try to access to this attribute fields which has not been created
causing an ospfd crash.

The patch simply check if the te parser has found a valid local address. If not
found, we stop the parser which avoid the crash.

Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit a73e66d07329d721f26f3f336f7735de420b0183)

11 months agobgpd: Ignore handling NLRIs if we received MP_UNREACH_NLRI
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.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit c37119df45bbf4ef713bc10475af2ee06e12f3bf)

11 months agobgpd: Treat EOR as withdrawn to avoid unwanted handling of malformed attrs
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:

```
router bgp 65001
 no bgp ebgp-requires-policy
 neighbor 127.0.0.1 remote-as external
 neighbor 127.0.0.1 passive
 neighbor 127.0.0.1 ebgp-multihop
 neighbor 127.0.0.1 disable-connected-check
 neighbor 127.0.0.1 update-source 127.0.0.2
 neighbor 127.0.0.1 timers 3 90
 neighbor 127.0.0.1 timers connect 1
 !
 address-family ipv4 unicast
  neighbor 127.0.0.1 addpath-tx-all-paths
  neighbor 127.0.0.1 default-originate
  neighbor 127.0.0.1 route-map RM_IN in
 exit-address-family
exit
!
route-map RM_IN permit 10
 set as-path prepend 200
exit
```

Send a malformed optional transitive attribute:

```
import socket
import time

OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")

KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")

UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff002b0200000003c0ff00010100eb00ac100b0b001ad908ac100b0b")

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(100)
s.close()
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 6814f2e0138a6ea5e1f83bdd9085d9a77999900b)

11 months agoMerge pull request #15932 from opensourcerouting/8.4-fix-build
David Lamparter [Mon, 6 May 2024 01:01:03 +0000 (03:01 +0200)]
Merge pull request #15932 from opensourcerouting/8.4-fix-build

11 months agobgpd: Use enum bgp_create_error_code as argument in header
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);
      |            ^~~~~~~~~~~~~~
```

Fixing stuff regarding GCC13.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit cc280c74cea8183b31f60ef16bda617eca364c9d)

11 months agoospf6d: fix uninitialized warnings
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]
```

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 55bbef1356418168833fba98d3e7d4691f8f1408)

11 months agolib: replace deprecated ares_gethostbyname
Andrew Cooks [Thu, 25 Apr 2024 07:18:39 +0000 (17:18 +1000)]
lib: replace deprecated ares_gethostbyname

c-ares has deprecated ares_gethostbyname() in version 1.28.0
Replace it with ares_getaddrinfo().

This fixes a build error on Fedora 40.

Signed-off-by: Andrew Cooks <acooks.at.bda@gmail.com>
(cherry picked from commit 89a2e4d8257a91d115fa29e02261c33312da5cba)
[equi: thread/event rename conflict fixed]

11 months agolib: replace deprecated ares_process()
Andrew Cooks [Wed, 24 Apr 2024 05:01:28 +0000 (15:01 +1000)]
lib: replace deprecated ares_process()

ares_process(...) has been deprecated.
Replace it with ares_process_fd(...)

Signed-off-by: Andrew Cooks <acooks.at.bda@gmail.com>
(cherry picked from commit 4540fa0a3e702f577d378b3fa1f5f26591a0a5ad)

11 months agoMerge pull request #15929 from FRRouting/mergify/bp/stable/8.4/pr-14645
David Lamparter [Sun, 5 May 2024 17:11:51 +0000 (19:11 +0200)]
Merge pull request #15929 from FRRouting/mergify/bp/stable/8.4/pr-14645

11 months agoMerge pull request #15931 from FRRouting/mergify/bp/stable/8.4/pr-14260
David Lamparter [Sun, 5 May 2024 17:11:29 +0000 (19:11 +0200)]
Merge pull request #15931 from FRRouting/mergify/bp/stable/8.4/pr-14260

11 months agoMerge pull request #15928 from FRRouting/mergify/bp/stable/8.4/pr-14245
David Lamparter [Sun, 5 May 2024 17:10:47 +0000 (19:10 +0200)]
Merge pull request #15928 from FRRouting/mergify/bp/stable/8.4/pr-14245

11 months agoMerge pull request #15926 from FRRouting/mergify/bp/stable/8.4/pr-12951
David Lamparter [Sun, 5 May 2024 17:10:04 +0000 (19:10 +0200)]
Merge pull request #15926 from FRRouting/mergify/bp/stable/8.4/pr-12951

Fix use beyond end of stream of labeled unicast parsing (backport #12951)

11 months agoMerge pull request #15925 from FRRouting/mergify/bp/stable/8.4/pr-12950
David Lamparter [Sun, 5 May 2024 17:09:39 +0000 (19:09 +0200)]
Merge pull request #15925 from FRRouting/mergify/bp/stable/8.4/pr-12950

fix #11808 to avoid infinite loops (backport #12950)

11 months agobgpd: Do not process NLRIs if the attribute length is zero
Donatas Abraitis [Tue, 22 Aug 2023 19:52:04 +0000 (22:52 +0300)]
bgpd: Do not process NLRIs if the attribute length is zero

```
3  0x00007f423aa42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26
4  0x00007f423aef9740 in core_handler (signo=11, siginfo=0x7fffc414deb0, context=<optimized out>) at lib/sigevent.c:246
5  <signal handler called>
6  0x0000564dea2fc71e in route_set_aspath_prepend (rule=0x564debd66d50, prefix=0x7fffc414ea30, object=0x7fffc414e400)
    at bgpd/bgp_routemap.c:2258
7  0x00007f423aeec7e0 in route_map_apply_ext (map=<optimized out>, prefix=prefix@entry=0x7fffc414ea30,
    match_object=match_object@entry=0x7fffc414e400, set_object=set_object@entry=0x7fffc414e400, pref=pref@entry=0x0) at lib/routemap.c:2690
8  0x0000564dea2d277e in bgp_input_modifier (peer=peer@entry=0x7f4238f59010, p=p@entry=0x7fffc414ea30, attr=attr@entry=0x7fffc414e770,
    afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_UNICAST, rmap_name=rmap_name@entry=0x0, label=0x0, num_labels=0, dest=0x564debdd5130)
    at bgpd/bgp_route.c:1772
9  0x0000564dea2df762 in bgp_update (peer=peer@entry=0x7f4238f59010, p=p@entry=0x7fffc414ea30, addpath_id=addpath_id@entry=0,
    attr=0x7fffc414eb50, afi=afi@entry=AFI_IP, safi=<optimized out>, safi@entry=SAFI_UNICAST, type=9, sub_type=0, prd=0x0, label=0x0,
    num_labels=0, soft_reconfig=0, evpn=0x0) at bgpd/bgp_route.c:4374
10 0x0000564dea2e2047 in bgp_nlri_parse_ip (peer=0x7f4238f59010, attr=attr@entry=0x7fffc414eb50, packet=0x7fffc414eaf0)
    at bgpd/bgp_route.c:6249
11 0x0000564dea2c5a58 in bgp_nlri_parse (peer=peer@entry=0x7f4238f59010, attr=attr@entry=0x7fffc414eb50,
    packet=packet@entry=0x7fffc414eaf0, mp_withdraw=mp_withdraw@entry=false) at bgpd/bgp_packet.c:339
12 0x0000564dea2c5d66 in bgp_update_receive (peer=peer@entry=0x7f4238f59010, size=size@entry=109) at bgpd/bgp_packet.c:2024
13 0x0000564dea2c901d in bgp_process_packet (thread=<optimized out>) at bgpd/bgp_packet.c:2933
14 0x00007f423af0bf71 in event_call (thread=thread@entry=0x7fffc414ee40) at lib/event.c:1995
15 0x00007f423aebb198 in frr_run (master=0x564deb73c670) at lib/libfrr.c:1213
16 0x0000564dea261b83 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:505
```

With the configuration:

```
frr version 9.1-dev-MyOwnFRRVersion
frr defaults traditional
hostname ip-172-31-13-140
log file /tmp/debug.log
log syslog
service integrated-vtysh-config
!
debug bgp keepalives
debug bgp neighbor-events
debug bgp updates in
debug bgp updates out
!
router bgp 100
 bgp router-id 9.9.9.9
 no bgp ebgp-requires-policy
 bgp bestpath aigp
 neighbor 172.31.2.47 remote-as 200
 !
 address-family ipv4 unicast
  neighbor 172.31.2.47 default-originate
  neighbor 172.31.2.47 route-map RM_IN in
 exit-address-family
exit
!
route-map RM_IN permit 10
 set as-path prepend 200
exit
!
```

The issue is that we try to process NLRIs even if the attribute length is 0.

Later bgp_update() will handle route-maps and a crash occurs because all the
attributes are NULL, including aspath, where we dereference.

According to the RFC 4271:

A value of 0 indicates that neither the Network Layer
         Reachability Information field nor the Path Attribute field is
         present in this UPDATE message.

But with a fuzzed UPDATE message this can be faked. I think it's reasonable
to skip processing NLRIs if both update_len and attribute_len are 0.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 28ccc24d38df1d51ed8a563507e5d6f6171fdd38)

11 months agobgpd: Check mandatory attributes more carefully for UPDATE message
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.

A crash:

```
bgpd[7834]: [TJ23Y-GY0RH] 127.0.0.1 Unknown attribute is received (type 31, length 16)
bgpd[7834]: [PCFFM-WMARW] 127.0.0.1(donatas-pc) rcvd UPDATE wlen 0 attrlen 20 alen 17
BGP[7834]: Received signal 11 at 1698089639 (si_addr 0x0, PC 0x55eefd375b4a); aborting...
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_backtrace_sigsafe+0x6d) [0x7f3205ca939d]
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_signal+0xf3) [0x7f3205ca9593]
BGP[7834]: /usr/local/lib/libfrr.so.0(+0xf5181) [0x7f3205cdd181]
BGP[7834]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980) [0x7f3204ff3980]
BGP[7834]: /usr/lib/frr/bgpd(+0x18ab4a) [0x55eefd375b4a]
BGP[7834]: /usr/local/lib/libfrr.so.0(route_map_apply_ext+0x310) [0x7f3205cd1290]
BGP[7834]: /usr/lib/frr/bgpd(+0x163610) [0x55eefd34e610]
BGP[7834]: /usr/lib/frr/bgpd(bgp_update+0x9a5) [0x55eefd35c1d5]
BGP[7834]: /usr/lib/frr/bgpd(bgp_nlri_parse_ip+0xb7) [0x55eefd35e867]
BGP[7834]: /usr/lib/frr/bgpd(+0x1555e6) [0x55eefd3405e6]
BGP[7834]: /usr/lib/frr/bgpd(bgp_process_packet+0x747) [0x55eefd345597]
BGP[7834]: /usr/local/lib/libfrr.so.0(event_call+0x83) [0x7f3205cef4a3]
BGP[7834]: /usr/local/lib/libfrr.so.0(frr_run+0xc0) [0x7f3205ca10a0]
BGP[7834]: /usr/lib/frr/bgpd(main+0x409) [0x55eefd2dc979]
```

Sending:

```
import socket
import time

OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")

KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")

UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff003c0200000014ff1f001000040146464646460004464646464646664646f50d05800100010200ffff000000")

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(1000)
s.close()
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit d8482bf011cb2b173e85b65b4bf3d5061250cdb9)

11 months agobgpd: Handle MP_REACH_NLRI malformed packets with session reset
Donatas Abraitis [Fri, 20 Oct 2023 14:49:18 +0000 (17:49 +0300)]
bgpd: Handle MP_REACH_NLRI malformed packets with session reset

Avoid crashing bgpd.

```
(gdb)
bgp_mp_reach_parse (args=<optimized out>, mp_update=0x7fffffffe140) at bgpd/bgp_attr.c:2341
2341 stream_get(&attr->mp_nexthop_global, s, IPV6_MAX_BYTELEN);
(gdb)
stream_get (dst=0x7fffffffe1ac, s=0x7ffff0006e80, size=16) at lib/stream.c:320
320 {
(gdb)
321 STREAM_VERIFY_SANE(s);
(gdb)
323 if (STREAM_READABLE(s) < size) {
(gdb)
34   return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb)

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)
```

With the configuration:

```
 neighbor 127.0.0.1 remote-as external
 neighbor 127.0.0.1 passive
 neighbor 127.0.0.1 ebgp-multihop
 neighbor 127.0.0.1 disable-connected-check
 neighbor 127.0.0.1 update-source 127.0.0.2
 neighbor 127.0.0.1 timers 3 90
 neighbor 127.0.0.1 timers connect 1
 address-family ipv4 unicast
  redistribute connected
  neighbor 127.0.0.1 default-originate
  neighbor 127.0.0.1 route-map RM_IN in
 exit-address-family
!
route-map RM_IN permit 10
 set as-path prepend 200
exit
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit b08afc81c60607a4f736f418f2e3eb06087f1a35)

11 months agobgpd: Don't read the first byte of ORF header if we are ahead of stream
Donatas Abraitis [Sun, 20 Aug 2023 19:15:27 +0000 (22:15 +0300)]
bgpd: Don't read the first byte of ORF header if we are ahead of stream

Reported-by: Iggy Frankovic iggyfran@amazon.com
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 9b855a692e68e0d16467e190b466b4ecb6853702)

11 months agobgpd: Fix use beyond end of stream of labeled unicast parsing
Donald Sharp [Sat, 4 Mar 2023 02:58:33 +0000 (21:58 -0500)]
bgpd: Fix use beyond end of stream of labeled unicast parsing

Fixes a couple crashes associated with attempting to read
beyond the end of the stream.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 7404a914b0cafe046703c8381903a80d3def8f8b)

11 months agobabeld: fix #11808 to avoid infinite loops
harryreps [Fri, 3 Mar 2023 23:17:14 +0000 (23:17 +0000)]
babeld: fix #11808 to avoid infinite loops

Replacing continue in loops to goto done so that index of packet buffer
increases.

Signed-off-by: harryreps <harryreps@gmail.com>
(cherry picked from commit ae1e0e1fed77716bc06f181ad68c4433fb5523d0)

13 months agoMerge pull request #15573 from opensourcerouting/fix/backport_bgp_filter_fun_8.4
Russ White [Tue, 19 Mar 2024 14:37:15 +0000 (10:37 -0400)]
Merge pull request #15573 from opensourcerouting/fix/backport_bgp_filter_fun_8.4

BGP memory backports

13 months agobgpd: Ensure community data is freed in some cases.
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>
13 months agobgpd: Include unsuppress-map as a valid outgoing policy
Donald Sharp [Sat, 2 Mar 2024 14:42:30 +0000 (09:42 -0500)]
bgpd: Include unsuppress-map as a valid outgoing policy

If unsuppress-map is setup for outgoing peers, consider that
policy is being applied as for RFC 8212.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
13 months agobgpd: Ensure that the correct aspath is free'd
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.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
14 months agoMerge pull request #15343 from FRRouting/mergify/bp/stable/8.4/pr-15327
Donald Sharp [Mon, 12 Feb 2024 02:34:29 +0000 (21:34 -0500)]
Merge pull request #15343 from FRRouting/mergify/bp/stable/8.4/pr-15327

pimd: re-evaluated S,G OILs upon RP changes and empty SG upstream oils (backport #15327)

14 months agopimd: re-evaluated S,G OILs upon RP changes and for empty SG upstream oils
Rajesh Varatharaj [Thu, 8 Feb 2024 02:58:39 +0000 (18:58 -0800)]
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.

Testing:
- Evpn pim tests - TestEvpnPimSingleVtepOneMdt.test_02_broadcast_traffic_spt_zero
- pim-smoke

Ticket: #
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit 071d43a052e04de52771b2f03461c407f0ced36f)

15 months agoMerge pull request #15232 from donaldsharp/null_argument_warning_8.4
Donald Sharp [Thu, 25 Jan 2024 14:33:54 +0000 (09:33 -0500)]
Merge pull request #15232 from donaldsharp/null_argument_warning_8.4

bgpd: fix NULL argument warning

15 months agobgpd: fix NULL argument warning
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>
15 months agoMerge pull request #15141 from FRRouting/mergify/bp/stable/8.4/pr-14664
Donald Sharp [Tue, 16 Jan 2024 15:41:40 +0000 (10:41 -0500)]
Merge pull request #15141 from FRRouting/mergify/bp/stable/8.4/pr-14664

isisd: staticd: need to link directly against libyang (backport #14664)

15 months agoisisd: staticd: need to link directly against libyang
Christian Hopps [Fri, 27 Oct 2023 02:51:08 +0000 (22:51 -0400)]
isisd: staticd: need to link directly against libyang

Signed-off-by: Christian Hopps <chopps@labn.net>
(cherry picked from commit 81d1d399521bb18f3fdd5353c9d58c4b3988f225)

18 months agoMerge pull request #14587 from FRRouting/mergify/bp/stable/8.4/pr-13340
Donald Sharp [Fri, 13 Oct 2023 15:39:35 +0000 (11:39 -0400)]
Merge pull request #14587 from FRRouting/mergify/bp/stable/8.4/pr-13340

zebra: Fix connected route deletion when multiple entry exists (backport #13340)

18 months agozebra: Fix connected route deletion when multiple entry exists
Xiao Liang [Thu, 20 Apr 2023 03:40:04 +0000 (11:40 +0800)]
zebra: Fix connected route deletion when multiple entry exists

When multiple interfaces have addresses in the same network, deleting
one of them may cause the wrong connected route being deleted.
For example:

    ip link add veth1 type veth peer veth2
    ip link set veth1 up
    ip link set veth2 up
    ip addr add dev veth1 192.168.0.1/24
    ip addr add dev veth2 192.168.0.2/24
    ip addr flush dev veth1

Zebra deletes the route of interface veth2 rather than veth1.

Should match nexthop against ere->re_nhe instead of ere->re->nhe.

Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
(cherry picked from commit a35ba7ba602f87390cc9cbce3f0ceb61977f0949)

19 months agoMerge pull request #14319 from opensourcerouting/fix/backport_530be6a4d089600f1028439...
Jafar Al-Gharaibeh [Thu, 31 Aug 2023 16:58:58 +0000 (11:58 -0500)]
Merge pull request #14319 from opensourcerouting/fix/backport_530be6a4d089600f1028439ddec420ef651b983b_8.4

ospfd: Prevent use after free( and crash of ospf ) when no router ospf

19 months agoospfd: Prevent use after free( and crash of ospf ) when no router ospf
Donald Sharp [Wed, 30 Aug 2023 14:33:29 +0000 (10:33 -0400)]
ospfd: Prevent use after free( and crash of ospf ) when no router ospf

Consider this config:

router ospf
  redistribute kernel

Then you issue:

no router ospf

ospf will crash with a use after free.

The problem is that the event's associated with the
ospf pointer were shut off then the ospf_external_delete
was called which rescheduled the event.  Let's just move
event deletion to the end of the no router ospf.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
19 months agoMerge pull request #14295 from FRRouting/mergify/bp/stable/8.4/pr-14290
Donald Sharp [Wed, 30 Aug 2023 13:21:23 +0000 (09:21 -0400)]
Merge pull request #14295 from FRRouting/mergify/bp/stable/8.4/pr-14290

bgpd: Use treat-as-withdraw for tunnel encapsulation attribute (backport #14290)

20 months agoMerge pull request #14298 from FRRouting/mergify/bp/stable/8.4/pr-14243
Donatas Abraitis [Wed, 30 Aug 2023 08:33:01 +0000 (11:33 +0300)]
Merge pull request #14298 from FRRouting/mergify/bp/stable/8.4/pr-14243

bgpd: Do not explicitly print MAXTTL value for ebgp-multihop vty output (backport #14243)

20 months agobgpd: Do not explicitly print MAXTTL value for ebgp-multihop vty output
Donatas Abraitis [Sun, 20 Aug 2023 21:01:42 +0000 (00:01 +0300)]
bgpd: Do not explicitly print MAXTTL value for ebgp-multihop vty output

1. Create /etc/frr/frr.conf
```
frr version 7.5
frr defaults traditional
hostname centos8.localdomain
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
line vty
router bgp 4250001000
  neighbor 192.168.122.207 remote-as 65512
  neighbor 192.168.122.207 ebgp-multihop
```

2. Start FRR
`# systemctl start frr
`
3. Show running configuration. Note that FRR explicitly set and shows the default TTL (225)

```
Building configuration...

Current configuration:
!
frr version 7.5
frr defaults traditional
hostname centos8.localdomain
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
router bgp 4250001000
 neighbor 192.168.122.207 remote-as 65512
 neighbor 192.168.122.207 ebgp-multihop 255
!
line vty
!
end
```
4. Copy initial frr.conf to frr.conf.new (no changes)
`# cp /etc/frr/frr.conf /root/frr.conf.new
`
5. Run frr-reload.sh:

```
$ /usr/lib/frr/frr-reload.py --test  /root/frr.conf.new
2023-08-20 20:15:48,050  INFO: Called via "Namespace(bindir='/usr/bin', confdir='/etc/frr', daemon='', debug=False, filename='/root/frr.conf.new', input=None, log_level='info', overwrite=False, pathspace=None, reload=False, rundir='/var/run/frr', stdout=False, test=True, vty_socket=None)"
2023-08-20 20:15:48,050  INFO: Loading Config object from file /root/frr.conf.new
2023-08-20 20:15:48,124  INFO: Loading Config object from vtysh show running

Lines To Delete
===============
router bgp 4250001000
 no neighbor 192.168.122.207 ebgp-multihop 255

Lines To Add
============
router bgp 4250001000
 neighbor 192.168.122.207 ebgp-multihop
```

Closes https://github.com/FRRouting/frr/issues/14242

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 767aaa3a80489bfc4ff097f932fc347e3db25b89)

20 months agobgpd: Use treat-as-withdraw for tunnel encapsulation attribute
Donatas Abraitis [Thu, 13 Jul 2023 19:32:03 +0000 (22:32 +0300)]
bgpd: Use treat-as-withdraw for tunnel encapsulation attribute

Before this path we used session reset method, which is discouraged by rfc7606.

Handle this as rfc requires.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit bcb6b58d9530173df41d3a3cbc4c600ee0b4b186)

20 months agoMerge pull request #14212 from opensourcerouting/fix/backport_fedf9119a1964abf8e476f2...
Donald Sharp [Wed, 16 Aug 2023 13:25:00 +0000 (09:25 -0400)]
Merge pull request #14212 from opensourcerouting/fix/backport_fedf9119a1964abf8e476f239d81b3f4ce385b1d_8.4

lib: Allow unsetting walltime-warning and cpu-warning

20 months agovtysh: Print uniq lines when parsing `no service ...`
Donatas Abraitis [Fri, 11 Aug 2023 15:21:12 +0000 (18:21 +0300)]
vtysh: Print uniq lines when parsing `no service ...`

Before this patch:

```
no service cputime-warning
no service cputime-warning
no ipv6 forwarding
no service cputime-warning
no service cputime-warning
no service cputime-warning
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
20 months agolib: Allow unsetting walltime-warning and cpu-warning
Donatas Abraitis [Fri, 11 Aug 2023 15:11:03 +0000 (18:11 +0300)]
lib: Allow unsetting walltime-warning and cpu-warning

With a negative form we get:

```
Internal CLI error [walltime_warning_str]
Internal CLI error [cputime_warning_str]
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
20 months agoMerge pull request #14191 from FRRouting/mergify/bp/stable/8.4/pr-14182
Donald Sharp [Sat, 12 Aug 2023 18:02:54 +0000 (14:02 -0400)]
Merge pull request #14191 from FRRouting/mergify/bp/stable/8.4/pr-14182

bgpd: evpn code was not properly unlocking rd_dest (backport #14182)

20 months agobgpd: evpn code was not properly unlocking rd_dest
Donald Sharp [Fri, 11 Aug 2023 13:53:42 +0000 (09:53 -0400)]
bgpd: evpn code was not properly unlocking rd_dest

Found some code where bgp was not unlocking the dest
and rd_dest when walking the tree attempting to
find something to install.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 1e8ac95bfb757b85d02514dd0f708974cdc22899)

20 months agoMerge pull request #14185 from FRRouting/mergify/bp/stable/8.4/pr-12524
Jafar Al-Gharaibeh [Sat, 12 Aug 2023 00:48:37 +0000 (19:48 -0500)]
Merge pull request #14185 from FRRouting/mergify/bp/stable/8.4/pr-12524

lib, zebra: Fix EVPN nexthop config order (backport #12524)

20 months agolib, zebra: Fix EVPN nexthop config order
Xiao Liang [Thu, 15 Dec 2022 09:04:32 +0000 (17:04 +0800)]
lib, zebra: Fix EVPN nexthop config order

Delay EVPN route addition to synchronize with rib_delete(), which now
uses early route queue.

Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
(cherry picked from commit cea3f7f25a23e485d4f814b670c11c92249568e1)

20 months agoMerge pull request #14134 from FRRouting/mergify/bp/stable/8.4/pr-14129
Donatas Abraitis [Thu, 3 Aug 2023 19:36:29 +0000 (22:36 +0300)]
Merge pull request #14134 from FRRouting/mergify/bp/stable/8.4/pr-14129

bgpd: Fix for session reset issue caused by malformed core attributes  in update message (backport #14129)

20 months agobgpd: Fix session reset issue caused by malformed core attributes
Samanvitha B Bhargav [Wed, 2 Aug 2023 06:10:35 +0000 (23:10 -0700)]
bgpd: Fix session reset issue caused by malformed core attributes

RCA:
On encountering any attribute error for core attributes in update message,
the error handling is set to 'treat as withdraw' and
further parsing of the remaining attributes is skipped.
But the stream pointer is not being correctly adjusted to
point to the next NLRI field skipping the rest of the attributes.
This leads to incorrect parsing of the NLRI field,
which causes BGP session to reset.

Fix:
The stream pointer offset is rightly adjusted to point to the NLRI field correctly
when the malformed attribute is encountered and remaining attribute parsing is skipped.

Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
(cherry picked from commit 70ff940fd1cbf920958116c558150ca5d3200eb8)

21 months agoMerge pull request #13957 from opensourcerouting/fix/route_map_cli_8.4
Donald Sharp [Tue, 11 Jul 2023 15:27:31 +0000 (11:27 -0400)]
Merge pull request #13957 from opensourcerouting/fix/route_map_cli_8.4

lib: make cmd_element->attr a bitmask & clarify

21 months agolib: make cmd_element->attr a bitmask & clarify
David Lamparter [Tue, 4 Oct 2022 11:30:04 +0000 (13:30 +0200)]
lib: make cmd_element->attr a bitmask & clarify

It already "looks" like a bitmask, but we currently can't flag a command
both YANG and HIDDEN at the same time.  It really should be a bitmask.

Also clarify DEPRECATED behaviour (or the absence thereof.)

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
21 months agoMerge pull request #13914 from opensourcerouting/fix/ospf6d_backports_8.4
Donald Sharp [Mon, 3 Jul 2023 12:34:34 +0000 (08:34 -0400)]
Merge pull request #13914 from opensourcerouting/fix/ospf6d_backports_8.4

ospf6d: Crash backports

21 months agoMerge pull request #13906 from FRRouting/mergify/bp/stable/8.4/pr-13895
Donatas Abraitis [Mon, 3 Jul 2023 07:49:58 +0000 (10:49 +0300)]
Merge pull request #13906 from FRRouting/mergify/bp/stable/8.4/pr-13895

ospfd: check for NULLs in ldp-igp sync json code (backport #13895)

21 months agoospf6d: Fix crash because neighbor structure was freed
Donald Sharp [Sat, 1 Jul 2023 15:18:06 +0000 (11:18 -0400)]
ospf6d: Fix crash because neighbor structure was freed

The loading_done event needs a event pointer to prevent
use after free's.  Testing found this:

    ERROR: AddressSanitizer: heap-use-after-free on address 0x613000035130 at pc 0x55ad42d54e5f bp 0x7ffff1e942a0 sp 0x7ffff1e94290
    READ of size 1 at 0x613000035130 thread T0
        #0 0x55ad42d54e5e in loading_done ospf6d/ospf6_neighbor.c:447
        #1 0x55ad42ed7be4 in event_call lib/event.c:1995
        #2 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
        #3 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
        #4 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #5 0x55ad42cf2b19 in _start (/usr/lib/frr/ospf6d+0x248b19)

    0x613000035130 is located 48 bytes inside of 384-byte region [0x613000035100,0x613000035280)
    freed by thread T0 here:
        #0 0x7f57998d77a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
        #1 0x55ad42e3b4b6 in qfree lib/memory.c:130
        #2 0x55ad42d5d049 in ospf6_neighbor_delete ospf6d/ospf6_neighbor.c:180
        #3 0x55ad42d1e1ea in interface_down ospf6d/ospf6_interface.c:930
        #4 0x55ad42ed7be4 in event_call lib/event.c:1995
        #5 0x55ad42ed84fe in _event_execute lib/event.c:2086
        #6 0x55ad42d26d7b in ospf6_interface_clear ospf6d/ospf6_interface.c:2847
        #7 0x55ad42d73f16 in ospf6_process_reset ospf6d/ospf6_top.c:755
        #8 0x55ad42d7e98c in clear_router_ospf6_magic ospf6d/ospf6_top.c:778
        #9 0x55ad42d7e98c in clear_router_ospf6 ospf6d/ospf6_top_clippy.c:42
        #10 0x55ad42dc2665 in cmd_execute_command_real lib/command.c:994
        #11 0x55ad42dc2b32 in cmd_execute_command lib/command.c:1053
        #12 0x55ad42dc2fa9 in cmd_execute lib/command.c:1221
        #13 0x55ad42ee3cd6 in vty_command lib/vty.c:591
        #14 0x55ad42ee4170 in vty_execute lib/vty.c:1354
        #15 0x55ad42eec94f in vtysh_read lib/vty.c:2362
        #16 0x55ad42ed7be4 in event_call lib/event.c:1995
        #17 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
        #18 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
        #19 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

    previously allocated by thread T0 here:
        #0 0x7f57998d7d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
        #1 0x55ad42e3ab22 in qcalloc lib/memory.c:105
        #2 0x55ad42d5c8ff in ospf6_neighbor_create ospf6d/ospf6_neighbor.c:119
        #3 0x55ad42d4c86a in ospf6_hello_recv ospf6d/ospf6_message.c:464
        #4 0x55ad42d4c86a in ospf6_read_helper ospf6d/ospf6_message.c:1884
        #5 0x55ad42d4c86a in ospf6_receive ospf6d/ospf6_message.c:1925
        #6 0x55ad42ed7be4 in event_call lib/event.c:1995
        #7 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
        #8 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
        #9 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Add an actual event pointer and just track it appropriately.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
21 months agoospf6d: Stop crash in ospf6_write
Donald Sharp [Fri, 30 Jun 2023 19:21:43 +0000 (15:21 -0400)]
ospf6d: Stop crash in ospf6_write

I'm seeing crashes in ospf6_write on the `assert(node)`.  The only
sequence of events that I see that could possibly cause this to happen
is this:

a) Someone has scheduled a outgoing write to the ospf6->t_write and
placed item(s) on the ospf6->oi_write_q
b) A decision is made in ospf6_send_lsupdate() to send an immediate
packet via a event_execute(..., ospf6_write,....).
c) ospf6_write is called and the oi_write_q is cleaned out.
d) the t_write event is now popped and the oi_write_q is empty
and FRR asserts on the `assert(node)` <crash>

When event_execute is called for ospf6_write, just cancel the t_write
event.  If ospf6_write has more data to send at the end of the function
it will reschedule itself.  I've only seen this crash one time and am
unable to reliably reproduce this at all.  But this is the only mechanism
that I can see that could make this happen, given how little the oi_write_q
is actually touched in code.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
21 months agoospfd: check for NULLs in vty code
Mark Stapp [Fri, 30 Jun 2023 13:44:00 +0000 (09:44 -0400)]
ospfd: check for NULLs in vty code

There were a couple of cli paths that NULL-checked in the
vtysh output path, but not in the json path.

Signed-off-by: Mark Stapp <mjs@labn.net>
(cherry picked from commit 864a3bc1855ec8027fec8d6f400adb44e1ecbfcf)

22 months agoMerge pull request #13820 from FRRouting/mergify/bp/stable/8.4/pr-13800
Mark Stapp [Tue, 20 Jun 2023 18:22:54 +0000 (14:22 -0400)]
Merge pull request #13820 from FRRouting/mergify/bp/stable/8.4/pr-13800

fix crashes in rip and ripng (backport #13800)

22 months agoRevert "ripngd: Cleanup memory allocations on shutdown"
Igor Ryzhov [Thu, 15 Jun 2023 14:42:05 +0000 (17:42 +0300)]
Revert "ripngd: Cleanup memory allocations on shutdown"

This reverts commit b1d29673ca16e558aea5d632da181555c83980cf.

This commit introduced a crash. When the VRF is deleted, the RIPNG
instance should not be freed, because the NB infrastructure still stores
the pointer to it. The instance should be deleted only when it's actually
deleted from the configuration.

To reproduce the crash:
```
frr# conf t
frr(config)# vrf vrf1
frr(config-vrf)# exit
frr(config)# router ripng vrf vrf1
frr(config-router)# exit
frr(config)# no vrf vrf1
frr(config)# no router ripng vrf vrf1
vtysh: error reading from ripngd: Resource temporarily unavailable (11)Warning: closing connection to ripngd because of an I/O error!
frr(config)#
```

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit 9f6dade90e5e4686f67ae17b42c2873ec7ca6532)

22 months agoRevert "ripd: Cleanup memory allocations on shutdown"
Igor Ryzhov [Thu, 15 Jun 2023 14:35:30 +0000 (17:35 +0300)]
Revert "ripd: Cleanup memory allocations on shutdown"

This reverts commit 3d1588d8ed537e3dbf120e1b2a5ad5b3c00c7897.

This commit introduced a crash. When the VRF is deleted, the RIP instance
should not be freed, because the NB infrastructure still stores the
pointer to it. The instance should be deleted only when it's actually
deleted from the configuration.

To reproduce the crash:
```
frr# conf t
frr(config)# vrf vrf1
frr(config-vrf)# exit
frr(config)# router rip vrf vrf1
frr(config-router)# exit
frr(config)# no vrf vrf1
frr(config)# no router rip vrf vrf1
vtysh: error reading from ripd: Resource temporarily unavailable (11)Warning: closing connection to ripd because of an I/O error!
frr(config)#
```

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit 054ca9b9ee760e23ac5d9f8d26d50e8fca78a887)

22 months agoFRR Release 8.4.4 frr-8.4.4
Jafar Al-Gharaibeh [Fri, 16 Jun 2023 04:31:44 +0000 (23:31 -0500)]
FRR Release 8.4.4

    This a convenience release/tag for house keeping. We currently don't plan to publish
    binary packages with this release.

    Changelog:

bfdd
    Fix malformed session with vrf
    Remove redundant nb destroy callbacks

bgpd
    Aggregate-address memory leak fix
    Bmp fix peer-up ports byte order
    Check 7 bytes for long-lived graceful-restart capability
    Conform bgp_packet.h with coding standards
    Copy the password from the previous peer on peer_xfer_config()
    Do not allow a `no router bgp xxx` when autoimport is happening
    Do not allow l3vni changes when shutting down
    Do not announce routes immediatelly on filter updates
    Ensure stream received has enough data
    Fix bgpd core when unintern attr
    Fix crash for `show bgp ... neighbor received-routes detail|prefix`
    Fix debug output for route-map names when using a unsuppress-map
    Fix ecommunity parsing for as4
    Fix for ain->attr corruption during path update
    Fix lcom->str string length to correctly cover aliases
    Increase buffer size used for dumping bgp to mrt files
    Limit flowspec to no attribute means a implicit withdrawal
    Make bgp_keepalives.c not use mtype_tmp
    Prevent null pointer deref when outputting data
    Treat withdraw variable as a bool
    Use interface name instead of pointer value
    Use the actual pointer type instead of a void

lib
    Adjust only `any` flag for prefix-list entries if destroying
    Destroy `any` flag when creating a prefix-list entry with prefix
    Fix link state memory leak
    Fix vtysh core when handling questionmark
    On bfd peer shutdown actually stop event

ospf6d
    Stop using mtype_tmp in some cases

ospfd, ospf6d
    Add more logging details

ospfd, ospfclient
    Do not just include .c files in another .c

ospfd
    Cleanup some memory leaks on shutdown in ospf_apiserver.c
    Fix for vitual-link crash in signal handler
    Fix interface param type update
    Fix memory leaks w/ `show ip ospf int x json` commands
    Fix ospf_lsa memory leak
    Fix ospf_ti_lfa drop of an entire table
    Fixing summary origination after range configuration
    Free up q_space in early return path
    Log adjacency changes with neighbor ip in addition to neighbor id
    Ospf opaque lsa stale processing fix and topotests.
    Remove mtype_tmp
    Respect loopback's cost that is set and set loopback costs to 0

pbrd
    Fix mismatching in match src-dst

pimd
    Fix use after free issue for ifp's moving vrfs
    Pim not sending register packets after changing from non dr to dr
    Process no-forward bsm packet

ripd
    Fix memory leak for ripd's route-map

tests
    Add test to validate 4-byte ecomm parsing
    Check if prefix-lists with ipv6 any works fine
    Check if route-map works correctly if modifying prefix-lists

tools
    Fix list value remove in frr-reload
    Fix missing remote-as configuration when reload
    Make check flag really work for reload

vtysh
    Give actual pam error messages

zebra
    Cleanup ctx leak on shutdown and turn off event
    Evpn handle del event for dup detected mac
    Fix evpn dup detected local mac del event
    Fix for heap-use-after-free in evpn
    Fix race during shutdown
    Install directly connected route after interface flap
    Reduce creation and fix memory leak of frrscripting pointers
    Unlock the route node when sending route notifications

Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
22 months agoMerge pull request #13782 from FRRouting/mergify/bp/stable/8.4/pr-12454
Donald Sharp [Tue, 13 Jun 2023 19:08:00 +0000 (15:08 -0400)]
Merge pull request #13782 from FRRouting/mergify/bp/stable/8.4/pr-12454

bgpd: Ensure stream received has enough data (backport #12454)

22 months agoMerge pull request #13785 from FRRouting/mergify/bp/stable/8.4/pr-13612
Donald Sharp [Tue, 13 Jun 2023 19:06:11 +0000 (15:06 -0400)]
Merge pull request #13785 from FRRouting/mergify/bp/stable/8.4/pr-13612

ospfd: fix interface param type update (backport #13612)

22 months agoospfd: fix interface param type update
Chirag Shah [Fri, 26 May 2023 20:43:50 +0000 (13:43 -0700)]
ospfd: fix interface param type update

interface link update event needs
to be handle properly in ospf interface
cache.

Example:
When vrf (interface) is created its default type
would be set to BROADCAST because ifp->status
is not set to VRF.
Subsequent link event sets ifp->status to vrf,
ospf interface update need to compare current type
to new default type which would be VRF (OSPF_IFTYPE_LOOPBACK).
Since ospf type param was created in first add event,
ifp vrf link event didn't update ospf type param which
leads to treat vrf as non loopback interface.

Ticket:#3459451
Testing Done:

Running config suppose to bypass rendering default
network broadcast for loopback/vrf types.

Before fix:

vrf vrf1
 vni 4001
exit-vrf
!
interface vrf1
 ip ospf network broadcast
exit

After fix: (interface vrf1 is not displayed).

vrf vrf1
 vni 4001
exit-vrf

Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 0d005b2d5c294d9d0a8db9d8beca83b97e0fd8ff)

22 months agobgpd: Ensure stream received has enough data
Donald Sharp [Tue, 6 Dec 2022 15:23:11 +0000 (10:23 -0500)]
bgpd: Ensure stream received has enough data

BGP_PREFIX_SID_SRV6_L3_SERVICE attributes must not
fully trust the length value specified in the nlri.
Always ensure that the amount of data we need to read
can be fullfilled.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 06431bfa7570f169637ebb5898f0b0cc3b010802)

22 months agoMerge pull request #13737 from FRRouting/mergify/bp/stable/8.4/pr-13645
Donatas Abraitis [Fri, 9 Jun 2023 06:10:50 +0000 (09:10 +0300)]
Merge pull request #13737 from FRRouting/mergify/bp/stable/8.4/pr-13645

bfdd: remove redundant nb destroy callbacks (backport #13645)

22 months agobfdd: remove redundant nb destroy callbacks
Igor Ryzhov [Wed, 31 May 2023 12:28:08 +0000 (15:28 +0300)]
bfdd: remove redundant nb destroy callbacks

Fixes warning logs:
```
2023/05/29 20:11:50 BFD: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-bfdd:bfdd/bfd/profile/minimum-ttl'
2023/05/29 20:11:50 BFD: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-bfdd:bfdd/bfd/sessions/multi-hop/minimum-ttl'
```

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit f7884aedf7a1249e3aae71b6a66c9a0f0915c4ef)

22 months agoMerge pull request #13713 from FRRouting/mergify/bp/stable/8.4/pr-13693
Donald Sharp [Wed, 7 Jun 2023 12:07:31 +0000 (08:07 -0400)]
Merge pull request #13713 from FRRouting/mergify/bp/stable/8.4/pr-13693

tools: fix list value remove in frr-reload (backport #13693)

22 months agotools: fix list value remove in frr-reload
Chirag Shah [Tue, 6 Jun 2023 04:48:12 +0000 (21:48 -0700)]
tools: fix list value remove in frr-reload

There might be a time element(s) from
temporary list are removed more than once
which leads to valueError in certain python3
version.

commit-id 1543f58b5 did not handle valueError
properly. This caused regression where
prefix-list config leads to delete followed
by add.

The new fix should just pass the exception as
value removal from list_to_add or list_to_del
is best effort.
This allows prefix-list config has no change
then removes the lines from lines_to_del and
lines_to_add properly.

Ticket:#3490252
Testing:

Configure prefix-list in frr.conf and perform
multiple frr-reload. After first reload operatoin
subsequent ones should not result in delete followed
by add of the prefix-list but rather no-op operation.

(Pdb) lines_to_add
[(('ip prefix-list FOO permit 10.2.1.0/24',), None)]
(Pdb) lines_to_del
[(('ip prefix-list FOO seq 5 permit 10.2.1.0/24',), None),
 (('ip prefix-list FOO seq 10 permit 10.2.1.0/24',), None)]
(Pdb) lines_to_del_to_del
[(('ip prefix-list FOO seq 5 permit 10.2.1.0/24',), None),
 (('ip prefix-list FOO seq 10 permit 10.2.1.0/24',), None)]
(Pdb) lines_to_add_to_del
[(('ip prefix-list FOO permit 10.2.1.0/24',), None),
 (('ip prefix-list FOO permit 10.2.1.0/24',), None)]
(Pdb) c
> /usr/lib/frr/frr-reload.py(1562)ignore_delete_re_add_lines()
-> return (lines_to_add, lines_to_del)
(Pdb) lines_to_add
[]
(Pdb) lines_to_del
[]

Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 9845c09d61a7e509bfae369648cb5f9893455ac4)

22 months agoMerge pull request #13695 from FRRouting/mergify/bp/stable/8.4/pr-13649
Donatas Abraitis [Tue, 6 Jun 2023 08:08:04 +0000 (11:08 +0300)]
Merge pull request #13695 from FRRouting/mergify/bp/stable/8.4/pr-13649

zebra: Unlock the route node when sending route notifications (backport #13649)

22 months agozebra: Unlock the route node when sending route notifications
Donald Sharp [Wed, 31 May 2023 15:40:07 +0000 (11:40 -0400)]
zebra: Unlock the route node when sending route notifications

When using a context to send route notifications to upper
level protocols, the code was using a locking function to
get the route node.  There is no need for this to be locked
as such FRR should free it up.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 82c6e4fea54eb65e153e6bc45bb718367b0b5132)