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 8c177d69e3)
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 5557a289ac)
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 f69d1313b1)
ospfv3 shows this unconditionally, and ospfv2 does not show `ip ospf network ...` if the type of the interface matches the specified network.
Fixes: https://github.com/FRRouting/frr/issues/15817
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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 a73e66d073)
frr-reload.py will walk through all config contexts and prepend no to the CLI
command. This requires that the vtysh shell code accepts a full command.
To Reproduce
vtysh -c "conf t" -c "router ospf" -c "router-info area"
vtysh -c "conf t" -c "router ospf" -c "no router-info area"
% Unknown command: no router-info area
vtysh -c "conf t" -c "router ospf" -c "no router-info"
Signed-off-by: Christian Breunig <christian@breunig.cc>
(cherry picked from commit e744db5098)
This fixes the initial implementation of commit 7743f2f8c0 ("OSPFd: Update
Segment Routing PR following review") where it wsa not possible to remove
the "segment-routing node-msd" CLI nodes via vtysh once segment-routing got
disabled.
Closes#14910
Signed-off-by: Christian Breunig <christian@breunig.cc>
(cherry picked from commit ba45aa62e7)
Traffic Engineering Database (TED) is fulfill from the various LSA advertised
and received by the router. To remove information on the TED, 2 mechanisms are
used: i) parse TE Opaque LSA when there are flushed and ii) compare the list of
prefixes advertised in the Router LSA with the list of corresponding edges and
subnets contained in the TED. However, this second mechanism assumes that the
Router LSA is unique and contains all prefixes of the advertised router.
But, this is wrong. Prefixes could be advertised with several Router LSA.
This conduct to remove edge and subnet in the TED while it should be maintained.
The result is a faulty test with ospf_sr_te_topo1 topotest when server is heavy
loaded.
This simple patch removed deletion of edges and subnets when parsing the Router
LSA and only removed them when the corresponding TE Opaque LSA is flushed. In
addition, TE Opaque LSA are not flushed when OSPF ajacency goes down. This
patch also correct this second problem.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit a3230323f7)
Segment Router Identifier (SID) could be an index (4 bytes) within a range
(SRGB or SRLB) or an MPLS label (3 bytes). Thus, before calling check_size
macro to verify SID TLVs size, it is mandatory to determine the SID type to
avoid wrong assert.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit 397dbbcae6)
Fix for the command "show ip ospf vrf NAME graceful-restart helper".
FRR did not show information by vrf's name.
If i have router ospf vrf red, vtysh's command
'show ip ospf vrf red graceful-restart helper' will not show anything.
But command 'show ip ospf vrf all graceful-restart helper' will work
normally. This fix fixes the display of information by vrf's name.
Example:
frr1# show ip ospf vrf vrf-1 graceful-restart helper
VRF Name: vrf-1
OSPF Router with ID (192.168.255.81)
Graceful restart helper support enabled.
Strict LSA check is enabled.
Helper supported for Planned and Unplanned Restarts.
Supported Graceful restart interval: 1800(in seconds).
Signed-off-by: teletajp <teletajp@yandex.ru>
(cherry picked from commit 62754e1029)
```
r1# sh ipv6 ospf6 summary-address
VRF Name: default
aggregation delay interval :5(in seconds)
```
Just hit this random and looks ugly, let's fix it.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit ed2b593720)
The problem was happening because the ospf->oiflist has this behaviour, each interface was removed and added at the end of the list in each ospf_network_run_subnet call, generation an infinite loop.
As a solution, a copy of the list was generated and we interacted with a fixed list.
Signed-off-by: Rodrigo Nardi <rnardi@netdef.org>
(cherry picked from commit e0dbeff5bc)
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
This patch includes:
* Implementation of RFC 5709 support in OSPF. Using
openssl library and FRR key-chain,
one can use SHA1, SHA256, SHA384, SHA512 and
keyed-MD5( backward compatibility with RFC 2328) HMAC algs.
* Updating documentation of OSPF
* add topotests for new HMAC algorithms
Signed-off-by: Mahdi Varasteh <varasteh@amnesh.ir>
Fixes a memory leak in ospfd where the external aggregator
was not released after its associated route node is deleted.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in ospf_basic_functionality.test_ospf_asbr_summary_topo1/r0.asan.ospfd.31502
=================================================================
==31502==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 200 byte(s) in 5 object(s) allocated from:
#0 0x7fdb30665d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fdb300620da in qcalloc lib/memory.c:105
#2 0x55e53c2da5fa in ospf_external_aggregator_new ospfd/ospf_asbr.c:396
#3 0x55e53c2dead3 in ospf_asbr_external_aggregator_set ospfd/ospf_asbr.c:1123
#4 0x55e53c27c921 in ospf_external_route_aggregation ospfd/ospf_vty.c:10264
#5 0x7fdb2ffe5428 in cmd_execute_command_real lib/command.c:993
#6 0x7fdb2ffe58ec in cmd_execute_command lib/command.c:1051
#7 0x7fdb2ffe5d6b in cmd_execute lib/command.c:1218
#8 0x7fdb3010ce2a in vty_command lib/vty.c:591
#9 0x7fdb3010d2d5 in vty_execute lib/vty.c:1354
#10 0x7fdb30115b9b in vtysh_read lib/vty.c:2362
#11 0x7fdb30100b99 in event_call lib/event.c:1979
#12 0x7fdb30045379 in frr_run lib/libfrr.c:1213
#13 0x55e53c1ccab4 in main ospfd/ospf_main.c:249
#14 0x7fdb2f65dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fdb30665d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fdb300620da in qcalloc lib/memory.c:105
#2 0x55e53c2da5fa in ospf_external_aggregator_new ospfd/ospf_asbr.c:396
#3 0x55e53c2dedd3 in ospf_asbr_external_rt_no_advertise ospfd/ospf_asbr.c:1182
#4 0x55e53c27cf10 in ospf_external_route_aggregation_no_adrvertise ospfd/ospf_vty.c:10626
#5 0x7fdb2ffe5428 in cmd_execute_command_real lib/command.c:993
#6 0x7fdb2ffe58ec in cmd_execute_command lib/command.c:1051
#7 0x7fdb2ffe5d6b in cmd_execute lib/command.c:1218
#8 0x7fdb3010ce2a in vty_command lib/vty.c:591
#9 0x7fdb3010d2d5 in vty_execute lib/vty.c:1354
#10 0x7fdb30115b9b in vtysh_read lib/vty.c:2362
#11 0x7fdb30100b99 in event_call lib/event.c:1979
#12 0x7fdb30045379 in frr_run lib/libfrr.c:1213
#13 0x55e53c1ccab4 in main ospfd/ospf_main.c:249
#14 0x7fdb2f65dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 240 byte(s) leaked in 6 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Addressed a memory leak in OSPF by fixing the improper deallocation of
area range nodes when removed from the table. Introducing a new function,
`ospf_range_table_node_destroy` for proper node cleanup, resolved the issue.
The ASan leak log for reference:
```
Direct leak of 56 byte(s) in 2 object(s) allocated from:
#0 0x7faf661d1d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7faf65bce1e9 in qcalloc lib/memory.c:105
#2 0x55a66e0b61cd in ospf_area_range_new ospfd/ospf_abr.c:43
#3 0x55a66e0b61cd in ospf_area_range_set ospfd/ospf_abr.c:195
#4 0x55a66e07f2eb in ospf_area_range ospfd/ospf_vty.c:631
#5 0x7faf65b51548 in cmd_execute_command_real lib/command.c:993
#6 0x7faf65b51f79 in cmd_execute_command_strict lib/command.c:1102
#7 0x7faf65b51fd8 in command_config_read_one_line lib/command.c:1262
#8 0x7faf65b522bf in config_from_file lib/command.c:1315
#9 0x7faf65c832df in vty_read_file lib/vty.c:2605
#10 0x7faf65c83409 in vty_read_config lib/vty.c:2851
#11 0x7faf65bb0341 in frr_config_read_in lib/libfrr.c:977
#12 0x7faf65c6cceb in event_call lib/event.c:1979
#13 0x7faf65bb1488 in frr_run lib/libfrr.c:1213
#14 0x55a66dfb28c4 in main ospfd/ospf_main.c:249
#15 0x7faf651c9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s).
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
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>
In scenarios where no backup paths are available, ensure proper
memory management by deleting `q_space->vertex_list`. This prevents
memory leaks.
The ASan leak log for reference:
```
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fcf8c70aa37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fcf8c2a8a45 in qcalloc ../lib/memory.c:105
#2 0x7fcf8c27d0cc in list_new ../lib/linklist.c:49
#3 0x55d6e8385e35 in ospf_spf_init ../ospfd/ospf_spf.c:540
#4 0x55d6e838c30d in ospf_spf_calculate ../ospfd/ospf_spf.c:1736
#5 0x55d6e83933cf in ospf_ti_lfa_generate_q_spaces ../ospfd/ospf_ti_lfa.c:673
#6 0x55d6e8394214 in ospf_ti_lfa_generate_p_space ../ospfd/ospf_ti_lfa.c:812
#7 0x55d6e8394c63 in ospf_ti_lfa_generate_p_spaces ../ospfd/ospf_ti_lfa.c:923
#8 0x55d6e8396390 in ospf_ti_lfa_compute ../ospfd/ospf_ti_lfa.c:1101
#9 0x55d6e838ca48 in ospf_spf_calculate_area ../ospfd/ospf_spf.c:1811
#10 0x55d6e838cd73 in ospf_spf_calculate_areas ../ospfd/ospf_spf.c:1840
#11 0x55d6e838cfb0 in ospf_spf_calculate_schedule_worker ../ospfd/ospf_spf.c:1871
#12 0x7fcf8c3922e4 in event_call ../lib/event.c:1979
#13 0x7fcf8c27c828 in frr_run ../lib/libfrr.c:1213
#14 0x55d6e82eeb6d in main ../ospfd/ospf_main.c:249
#15 0x7fcf8bd59d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Coverity is complaining that listnode can return a NULL
value and thus FRR could derefence the returned value.
Since this is not crashing we know that this is not happening
in the wild. Let's make this an assert or check that it is
legal to use the value.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently, when changing ABR type on a working router, SPF recalculation
will only be initiated if the OSPF flags have changed after this.
Otherwise, SPF recalculation will be omitted and OSPF RIB update will
not occur. In other words, changing ABR type might not result in
inter-area routes addition/deletion.
With this fix, when ABR type is changed, the command handler initiates
SPF recalculation.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Include an event ptr-to-ptr in the event_execute() api
call, like the various schedule api calls. This allows the
execute() api to cancel an existing scheduled task if that
task is being executed inline.
Signed-off-by: Mark Stapp <mjs@labn.net>
Currently, when redistribution of routes was configured, external LSAs
were already advertised to peers, and then default-metric is changed,
external LSAs refresh will not occur. In other words, the peers will not
receive the refreshed external LSAs with the new metric.
With this fix, changing default-metric will cause external LSAs to be
refreshed and flooded.
There is a similar task to refresh external LSAs when NSSA settings are
changed. And there is a function that accomplishes it -
ospf_schedule_asbr_nssa_redist_update(). Since the function does the
general work of refreshing external LSAs and is not specific to NSSA
settings, the idea is to give it a more general name and call it when
default-metric changes in order to fix the problem.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
User can now use 'show ip ospf route detail' command to distinguish
intra-area stub network and transit network.
Transit network will be displayed as 'N T prefix ...'.
NOTICE: Json output format has been changed, intra-area transit networks
will have a new attribute 'transit' and value is 'true'.
And 'adv' (means advertise router) change to 'advertisedRouter'.
Example output:
bsp-debianrt-exp1# show ip ospf route detail
Codes: N - network T - transitive
IA - inter-area E - external route
D - destination R - router
============ OSPF network routing table ============
N T 10.0.0.0/24 [32] area: 0.0.0.0
via 192.168.124.67, ens192
adv 10.0.0.5
N 10.0.30.0/24 [33] area: 0.0.0.0
via 192.168.124.67, ens192
adv 10.0.0.5
...
Signed-off-by: Zhiyuan Wan <h@iloli.bid>
The ospfd mistakenly copy advertise router from vertex->id, which may
not be correct in an OSPF transit network.
Signed-off-by: Zhiyuan Wan <h@iloli.bid>
Some fixes for the per-interface write sockets: better align
opening and closing them with ospf config actions; set
read buffer to zero since these sockets are used only for
writing packets.
Signed-off-by: Mark Stapp <mjs@labn.net>
Add support for "[no] ip ospf capbility opaque" at the interface
level with the default being capability opaque enabled. The command
"no ip ospf capability opaque" will disable opaque LSA database
exchange and flooding on the interface. A change in configuration
will result in the interface being flapped to update our options
for neighbors but no attempt will be made to purge existing LSAs
as in dense topologies, these may received by neighbors through
different interfaces.
Topotests are added to test both the configuration and the LSA
opaque flooding suppression.
Signed-off-by: Acee <aceelindem@gmail.com>
When running all daemons with config for most of them, FRR has
sharpd@janelle:~/frr$ vtysh -c "show debug hashtable" | grep "VRF BIT HASH" | wc -l
3570
3570 hashes for bitmaps associated with the vrf. This is a very
large number of hashes. Let's do two things:
a) Reduce the created size of the actually created hashes to 2
instead of 32.
b) Delay generation of the hash *until* a set operation happens.
As that no hash directly implies a unset value if/when checked.
This reduces the number of hashes to 61 in my setup for normal
operation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
