==13211==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000af158 at pc 0x55d48c5f1e38 bp 0x7fffd8a713d0 sp 0x7fffd8a713c0
READ of size 8 at 0x6020000af158 thread T0
#0 0x55d48c5f1e37 in rip_allow_ecmp ripd/rip_cli.c:98
#1 0x7f2ec125aa0f in cmd_execute_command_real lib/command.c:990
#2 0x7f2ec125ae90 in cmd_execute_command lib/command.c:1049
#3 0x7f2ec125b406 in cmd_execute lib/command.c:1217
#4 0x7f2ec137ca36 in vty_command lib/vty.c:551
#5 0x7f2ec137ce52 in vty_execute lib/vty.c:1314
#6 0x7f2ec1384f9e in vtysh_read lib/vty.c:2223
#7 0x7f2ec137041b in event_call lib/event.c:1995
#8 0x7f2ec12b54bf in frr_run lib/libfrr.c:1204
#9 0x55d48c5f0f32 in main ripd/rip_main.c:171
#10 0x7f2ec0ad9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#11 0x55d48c5f1349 in _start (/usr/lib/frr/ripd+0x3b349)
0x6020000af158 is located 0 bytes to the right of 8-byte region [0x6020000af150,0x6020000af158)
allocated by thread T0 here:
#0 0x7f2ec18ccb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f2ec12d2e41 in qmalloc lib/memory.c:100
#2 0x7f2ec125a815 in cmd_execute_command_real lib/command.c:955
#3 0x7f2ec125ae90 in cmd_execute_command lib/command.c:1049
#4 0x7f2ec125b406 in cmd_execute lib/command.c:1217
#5 0x7f2ec137ca36 in vty_command lib/vty.c:551
#6 0x7f2ec137ce52 in vty_execute lib/vty.c:1314
#7 0x7f2ec1384f9e in vtysh_read lib/vty.c:2223
#8 0x7f2ec137041b in event_call lib/event.c:1995
#9 0x7f2ec12b54bf in frr_run lib/libfrr.c:1204
#10 0x55d48c5f0f32 in main ripd/rip_main.c:171
#11 0x7f2ec0ad9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: heap-buffer-overflow ripd/rip_cli.c:98 in rip_allow_ecmp
Shadow bytes around the buggy address:
0x0c048000ddd0: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa
0x0c048000dde0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
0x0c048000ddf0: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fd
0x0c048000de00: fa fa fd fa fa fa fd fd fa fa 00 03 fa fa fd fa
0x0c048000de10: fa fa fd fa fa fa 00 00 fa fa fd fa fa fa 00 03
=>0x0c048000de20: fa fa 00 03 fa fa fd fa fa fa 00[fa]fa fa fa fa
0x0c048000de30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c048000de40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c048000de50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c048000de60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c048000de70: 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
==13211==ABORTING
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The output of show bgp all json is inconsistent across Address-families
i.e. ipv4/ipv6 is a no pretty format while l2vpn-evpn is in a pretty
format. For huge scale (lots of routes with lots of paths), it is better
to use no_pretty format.
Before fix:
torm-11# sh bgp all json
{
"ipv4Unicast":{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 1,
"routerId": "27.0.0.15",
"defaultLocPrf": 100,
"localAS": 65000,
"routes": { } }
,
"l2VpnEvpn":{
"routes":{
"27.0.0.15:2":{
"rd":"27.0.0.15:2",
"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{
"prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]",
"prefixLen":352,
"paths":[
<SNIP>.............
After fix:
torm-11# sh bgp all json
{
"ipv4Unicast":{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 1,
"routerId": "27.0.0.15",
"defaultLocPrf": 100,
"localAS": 65000,
"routes": { } }
,
"l2VpnEvpn":{
"routes":{"27.0.0.15:2":{"rd":"27.0.0.15:2","[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{"prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]","prefixLen":352,"paths":[[{"valid":true,"bestpath":true,"selectionReason":"First path received","pathFrom":"external","routeType":1,"weight":32768,"peerId":"(unspec)","path":"","origin":"IGP","extendedCommunity"
<SNIP>.............
Issue: 3472865
Ticket:#3472865
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
In the json output of show bgp all json, the l2VpnEvpn afi-safi is
missing the 'routes' key making the json output format invalid.
Before Fix:
torm-11# sh bgp all json
{
<SNIP>....................
"l2VpnEvpn":{
{
"27.0.0.15:2":{
"rd":"27.0.0.15:2",
"[4]:[03:44:38:39:ff:ff:01:00:00:01]:[32]:[27.0.0.15]":{
"prefix":"[4]:[03:44:38:39:ff:ff:01:00:00:01]:[32]:[27.0.0.15]",
"prefixLen":352,
"paths":[
<SNIP>....................
After Fix:
torm-11# sh bgp all json
{
<SNIP>....................
"l2VpnEvpn":{
"routes":{
"27.0.0.15:2":{
"rd":"27.0.0.15:2",
"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{
"prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]",
"prefixLen":352,
"paths":[
Issue: 3472865
Ticket:#3472865
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
There is no path in some functions where the ctx
has not already been de-refed. As such no need
to test for it's existence.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When running the pytests in parallel, calling pytest.exit() causes
the entire test run to be aborted. Which.... Is frankly not cool.
Let's notice the failure and move on to the next tests.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A bunch of tests rely on pre-generated config from
json files. These tests were not putting `exit` stanzas
and a bunch of the tests as a result are silently failing
to configure properly at all, as commands were being sent
to the wrong daemons.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The test is performing these steps:
a) get timestamp of route installed in zebra
b) <make changes>
c) get new timestamp of route installed in zebra
If < 1 second happens between A and C the test
assumes that something went wrong, as that it is
testing to see if the route was reinstalled <yes I know>.
Just sleep 1 second after a) happens so that if a reinstall
happens we can easily see it, and we also know that if a
reinstall doesn't happen then the new timestamp will
always be 1 second or greater.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This can lead into some garbage outputs, that can't be decoded in utf-8 or so.
This was catched when testing 76b246aa1f.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Based on RFC-4760, if NEXT_HOP attribute is not
suppose to be set if MP_REACH_NLRI NLRI is used.
for IPv4 aggregate route only NEXT_HOP attribute
with ipv4 prefixlen needs to be set.
Testing Done:
Before fix:
----------
aggregate route:
*> 184.123.0.0/16 ::(TORC11) 0 32768 i
After fix:
---------
aggregate route:
*> 184.123.0.0/16 0.0.0.0(TORC11) 0 32768 i
* i peerlink-3 0 100 0 i
* uplink1 0 4435 5546 i
184.123.1.0/24 0.0.0.0(TORC11) 0 32768 i
s> 184.123.8.0/22 0.0.0.0(TORC11) 0 32768 i
Signed-off-by: Chirag Shah <chirag@nvidia.com>
In ebgp+ ibgp deployment aggregate summary-only route
selected path should always be locally originated
summary route.
When aggregate route summary-only config is removed
The selected path is iBGP peer as its lower cost
Upon reconfiguring aggregate route summary-only,
the locally originated is not selected due to
always choosing first path attribute and bailing
out as no change in route update.
Ticket:#3467890
Issue:3467890
Testing Done:
Config:
------
TORC11(config-router)#router bgp
TORC11(config-router)# address-family ipv4 unicast
TORC11(config-router-af)# aggregate-address 184.123.0.0/16
summary-only
TORC11(config-router-af)# no aggregate-address 184.123.0.0/16
summary-only
TORC11(config-router-af)# aggregate-address 184.123.0.0/16
summary-only
Before fix:
-----------
*> 184.123.0.0/16 ::(TORC11) 0 32768 i
* uplink1 0 4435 5546 i
* uplink2 0 4435 5546 i
* i peerlink-3 0 100 0 i
After fix:
----------
*> 184.123.0.0/16 ::(TORC11) 0 32768 i
* i peerlink-3 0 100 0 i
* uplink2 0 4435 5546 i
* uplink1 0 4435 5546 i
Signed-off-by: Chirag Shah <chirag@nvidia.com>
From running the test:
bgp_remove_private_as/test_bgp_remove_private_as.py::test_bgp_remove_private_as
/home/sharpd/.local/lib/python3.10/site-packages/_pytest/python.py:198: PytestReturnNotNoneWarning: Expected None, but bgp_remove_private_as/test_bgp_remove_private_as.py::test_bgp_remove_private_as returned True, which will be an error in a future version of pytest. Did you mean to use `assert` instead of `return`?
warnings.warn(
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When shutting down zebra, the hook for the rmac update was
not being unregistered. As such it would be possible
to get into a condition where more rmacs are being
added to the queue for handling in the future after we
are told to shutdown.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The t_conn_down pointer was being set to NULL when it already
was. The t_conn_down pointer was being dropped( and leaving
a thread possibly running in the background ) which could
cause problems on shutdown. And finally when shutting down
the t_conn_down event was not being stopped at all.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
On shutdown, the old FPM queues up dests to be sent to
the FPM listener. This is done through the rib_shutdown
hook. Which is called when the table that the routes are
stored in are being deleted. This dest has pointers
to the rnode. The rnode has pointers to the table it
is associated with as well as the table->info pointer for
the zebra data associated with this table.
The FPM after this attempts to tell this to it's listener
via events. Unfortunately the zvrf, table_id and nl_pid
was being grabbed from memory that had been freed! Since
all this can be grabbed from memory that has not been freed
on shutdown let's switch over to using that instead of freed
memory for gathering data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
`ccls` needs information from FRR build configuration to work,
so allow creation of a custom ccls config during autoconf.
Paraphrasing the doc entry: ccls is a very powerful tool that allows
dev environments to provide sophisticated IDE functionality, e.g.,
semantically aware jumps and code refactoring...
Signed-off-by: Christian Hopps <chopps@labn.net>
