Igor Ryzhov [Tue, 9 Feb 2021 18:38:45 +0000 (21:38 +0300)]
vrf: mark vrf as configured when entering vrf node
The VRF must be marked as configured when user enters "vrf NAME" command.
Otherwise, the following problem occurs:
`ip link add red type vrf table 1`
VRF structure is allocated.
`vtysh -c "conf t" -c "vrf red"`
`lib_vrf_create` is called, and pointer to the VRF structure is stored
to the nb_config_entry.
`ip link del red`
VRF structure is freed (because it is not marked as configured), but
the pointer is still stored in the nb_config_entry.
`vtysh -c "conf t" -c "no vrf red"`
Nothing happens, because VRF structure doesn't exist. It means that
`lib_vrf_destroy` is not called, and nb_config_entry still exists in
the running config with incorrect pointer.
`ip link add red type vrf table 1`
New VRF structure is allocated.
`vtysh -c "conf t" -c "vrf red"`
`lib_vrf_create` is NOT called, because the nb_config_entry for that
VRF name still exists in the running config.
After that all NB commands for this VRF will use incorrect pointer to
the freed VRF structure.
zyxwvu Shi [Mon, 8 Feb 2021 12:09:02 +0000 (20:09 +0800)]
bgpd: Do not compare attr again.
`same_attr` has been computed and `hook_call(bgp_process)` (calling
BMP module) would not change it. We could reuse the value to filter
same attribute updates, avoiding an extra comparison.
Donald Sharp [Sun, 7 Feb 2021 20:03:51 +0000 (15:03 -0500)]
bfdd: Prevent use after free ( again )
Valgrind is still reporting:
466020-==466020== by 0x11B9F4: main (bfdd.c:403)
466020-==466020== Address 0x5a7d544 is 84 bytes inside a block of size 272 free'd
466020:==466020== at 0x48399AB: free (vg_replace_malloc.c:538)
466020-==466020== by 0x490A947: qfree (memory.c:140)
466020-==466020== by 0x48F2AE8: if_delete (if.c:322)
466020-==466020== by 0x48F250D: if_destroy_via_zapi (if.c:195)
466020-==466020== by 0x497071E: zclient_interface_delete (zclient.c:2040)
466020-==466020== by 0x49745F6: zclient_read (zclient.c:3687)
466020-==466020== by 0x4955AEC: thread_call (thread.c:1684)
466020-==466020== by 0x48FF64E: frr_run (libfrr.c:1126)
466020-==466020== by 0x11B9F4: main (bfdd.c:403)
466020-==466020== Block was alloc'd at
466020:==466020== at 0x483AB65: calloc (vg_replace_malloc.c:760)
466020-==466020== by 0x490A805: qcalloc (memory.c:115)
466020-==466020== by 0x48F23D6: if_new (if.c:160)
466020-==466020== by 0x48F257F: if_create_name (if.c:214)
466020-==466020== by 0x48F3493: if_get_by_name (if.c:558)
466020-==466020== by 0x49705F2: zclient_interface_add (zclient.c:1989)
466020-==466020== by 0x49745E0: zclient_read (zclient.c:3684)
466020-==466020== by 0x4955AEC: thread_call (thread.c:1684)
466020-==466020== by 0x48FF64E: frr_run (libfrr.c:1126)
466020-==466020== by 0x11B9F4: main (bfdd.c:403)
Apparently the bs->ifp pointer is being set even in cases when
the bs->key.ifname is not being set. So go through and just
match the interface pointer and cut-to-the-chase.
Donald Sharp [Sun, 7 Feb 2021 19:59:53 +0000 (14:59 -0500)]
*: Fix usage of bfd_adj_event
Valgrind reports:
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A090D: bgp_bfd_dest_update (bgp_bfd.c:416)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A093C: bgp_bfd_dest_update (bgp_bfd.c:421)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
On looking at bgp_bfd_dest_update the function call into bfd_get_peer_info
when it fails to lookup the ifindex ifp pointer just returns leaving
the dest and src prefix pointers pointing to whatever was passed in.
Let's do two things:
a) The src pointer was sometimes assumed to be passed in and sometimes not.
Forget that. Make it always be passed in
b) memset the src and dst pointers to be all zeros. Then when we look
at either of the pointers we are not making decisions based upon random
data in the pointers.
bgpd: Dump BGP attrs to check what's the actual prefix with aggr_as 0
Just for more debug information regarding malformed aggregator_as.
```
bgpd[5589]: [EC 33554434] 192.168.10.25: AGGREGATOR AS number is 0 for aspath: 65030
bgpd[5589]: bgp_attr_aggregator: attributes: nexthop 192.168.10.25, origin i, path 65030
```
Mark Stapp [Wed, 3 Feb 2021 21:28:18 +0000 (16:28 -0500)]
tests: fix ospf6_topo1 missing ref files
Only one of the four reference files was present; add the missing
three. The test just silently passed if a ref file was missing:
change that to a failure.
Wesley Coakley [Tue, 2 Feb 2021 23:16:51 +0000 (18:16 -0500)]
doc: cross compilation guide
Wrote a little guide for cross-compiling FRR, gleaned from notes I took
while compiling for a RPi 3B+ on a Gentoo x86_64 system.
Care was taken to keep this documentation as generic as possible so
these steps could be applied to any cross-compile targeting a supported
architecture.
bgpd: Drop aggregator_as attribute if malformed in case of BGP_AS_ZERO
An UPDATE message that contains the AS number of zero in the AS_PATH
or AGGREGATOR attribute MUST be considered as malformed and be
handled by the procedures specified in [RFC7606].
An UPDATE message with a malformed AGGREGATOR attribute SHALL be
handled using the approach of "attribute discard".
Attribute discard: In this approach, the malformed attribute MUST
be discarded and the UPDATE message continues to be processed.
This approach MUST NOT be used except in the case of an attribute
that has no effect on route selection or installation.
Pat Ruddy [Mon, 1 Jun 2020 13:33:30 +0000 (14:33 +0100)]
zebra: resolve multiple functions for local MAC delete
the old VXLAN function for local MAC deletion was still in
existence and being called from the VXLAN code whilst the new
generic function was not being called at all. Resolve this so
the generic function matches the old function and is called
exclusively.
David Lamparter [Tue, 2 Feb 2021 20:05:50 +0000 (21:05 +0100)]
lib/xref: fix frrtrace() calls in thread code
This didn't exist yet when the xref code came around, and since
frrtrace() gets collapsed to nothing by the preprocessor when
tracepoints are disabled, it didn't cause any compiler errors...
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Tue, 2 Feb 2021 18:38:38 +0000 (19:38 +0100)]
lib/xref: work around GCC bug 41091
gcc fucks up global variables with section attributes when they're used
in templated C++ code. The template instantiation "magic" kinda breaks
down (it's implemented through COMDAT in the linker, which clashes with
the section attribute.)
The workaround provides full runtime functionality, but the xref
extraction tool (xrelfo.py) won't work on C++ code compiled by GCC.
FWIW, clang gets this right.
Signed-off-by: David Lamparter <equinox@diac24.net>
bgpd: config connect timer is not applied immediately for peers in non-established state.
Description:
When user is config connect timer, it doesn't reflect
immediately. It reflect when next time neighbor is tried to reconnect.
Problem Description/Summary :
When user is config connect timer, it doesn't reflect
The network connection was aborted by the local system.d to reconnect.
Fix is to update the connect timer immediately if BGP
session is not in establish state.
Expected Behavior :
If neighbor is not yet established, we should immediately apply the config connect timer to the peer.
lynne [Sat, 30 Jan 2021 00:36:22 +0000 (19:36 -0500)]
isisd: When adjacencies go up and down add support to modify attached-bit
When adjacencies change state the attached-bits in LSPs in other areas
on the router may need to be modified.
1. If a router no longer has a L2 adjacency to another area the
attached-bit must no longer be sent in the LSP
2. If a new L2 adjacency comes up in a different area then the
attached-bit should be sent in the LSP
Stephen Worley [Mon, 11 Jan 2021 22:30:21 +0000 (17:30 -0500)]
zebra: move pbr hash create after update release
Move the pbr hash creation to be after the update release
and dplane install. Now that rules are installed in a separate
dplane pthread, we can have scenarios where we have an interface
flapping and we install/remove rules sufficiently fast enough we
could issue what we think is an update for an identical rule and
end up releasing the rule right after we created it and sent it to
the dplane. This solves the problem of recving duplicate rules
during interface flapping.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Stephen Worley [Thu, 7 Jan 2021 20:28:28 +0000 (15:28 -0500)]
pbrd: nht only handle if updates if IPV*_IFINDEX nh
Only handle an interface update in the nexthop tracking code
if the nexthop in question was set with an interface to point
out of. If the nexthop is GW only, the interface update could
be unrelated but have overlapping address space. Let that be
handled elsewhere.
Ex)
```
5.5.5.0/30 dev dummyDoof proto kernel scope link src 5.5.5.1
5.5.5.0/24 dev goofDummy proto kernel scope link src 5.5.5.1
[root@alfred frr-2]# ip ro show table 10000
default via 5.5.5.2 dev dummyDoof proto pbr metric 20
[root@alfred frr-2]# ip link set goofDummy down
[root@alfred frr-2]# ip ro show table 10000
[root@alfred frr-2]# ip link set goofDummy up
[root@alfred frr-2]# ip ro show table 10000
```
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Stephen Worley [Wed, 27 Jan 2021 21:20:22 +0000 (16:20 -0500)]
zebra: disallow resolution to duplicate nexthops
Disallow the resolution to nexthops that are marked duplicate.
When we are resolving to an ecmp group, it's possible this
group has duplicates.
I found this when I hit a bug where we can have groups resolving
to each other and cause the resolved->next->next pointer to increase
exponentially. Sufficiently large ecmp and zebra will grind to a hault.
Like so:
```
D> 4.4.4.14/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:02
* via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
via 4.4.4.1 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.2 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.3 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.4 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.5 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.6 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.7 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.8 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.9 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.10 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.11 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.12 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.13 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.15 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 4.4.4.16 (recursive), weight 1, 00:00:02
via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
via 1.1.1.1, dummy1, weight 1, 00:00:02
D> 4.4.4.15/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:09
* via 1.1.1.1, dummy1 onlink, weight 1, 00:00:09
via 4.4.4.1 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.2 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.3 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.4 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.5 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.6 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.7 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.8 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.9 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.10 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.11 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.12 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.13 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.14 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 4.4.4.16 (recursive), weight 1, 00:00:09
via 1.1.1.1, dummy1 onlink, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
via 1.1.1.1, dummy1, weight 1, 00:00:09
D> 4.4.4.16/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:19
* via 1.1.1.1, dummy1 onlink, weight 1, 00:00:19
via 4.4.4.1 (recursive), weight 1, 00:00:19
via 1.1.1.1, dummy1, weight 1, 00:00:19
via 4.4.4.2 (recursive), weight 1, 00:00:19
Then use sharpd to install 4.4.4.16 -> 4.4.4.1 pointing to that nexthop
group in decending order.
```
With these changes it prevents the growing ecmp above by disallowing
duplicates to be in the resolution decision. These nexthops are not
installed anyways so why should we be resolving to them?
Signed-off-by: Stephen Worley <sworley@nvidia.com>
David Lamparter [Mon, 1 Feb 2021 16:50:01 +0000 (17:50 +0100)]
lib/printf: disable `%n` specifier
We don't use `%n` anywhere, so the only purpose it serves is enabling
exploits.
(I thought about this initially when adding printfrr, but I wasn't sure
we don't use `%n` anywhere, and thought I'll check later, and then just
forgot it...)
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Thu, 30 Apr 2020 19:33:11 +0000 (21:33 +0200)]
lib/xref: put setup calls in libraries
Our "true" libraries (i.e. not modules) don't invoke neither
FRR_DAEMON_INFO nor FRR_MODULE_SETUP, hence XREF_SETUP isn't invoked
either. Invoke it directly to get things working.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Thu, 9 Aug 2018 20:50:19 +0000 (22:50 +0200)]
lib: "xref" identifier infrastructure
This adds the machinery for cross reference points (hence "xref") for
things to be annotated with source code location or other metadata
and/or to be uniquely identified and found at runtime or by dissecting
executable files.
The extraction tool to walk down an ELF file is done and working but
needs some more cleanup and will be added in a separate commit.
Signed-off-by: David Lamparter <equinox@diac24.net>
Donald Sharp [Mon, 1 Feb 2021 15:14:38 +0000 (10:14 -0500)]
bgpd: Centralize the dest unlocking for adj_out data structure
When FRR creates a adj_out data structure we lock the `struct
bgp_dest` node associated with it. On freeing of this data
structure and removing the lock it was not associated with
the actual free of the adjacency structure. Let's clean up
the lock/unlock to be centralized to the alloc/free of the adj_out.
Donald Sharp [Thu, 28 Jan 2021 16:25:51 +0000 (11:25 -0500)]
lib: Line up `show thread cpu` output appropriately
The output from `show thread cpu` was not lined up appropriately
for the header line. As well as the function name we were
calling in the output. Fix it.
Donald Sharp [Sun, 31 Jan 2021 13:56:00 +0000 (08:56 -0500)]
zebra: Prevent sending of unininted data
valgrind is reporting: 2448137-==2448137== Thread 5 zebra_apic: 2448137-==2448137== Syscall param writev(vector[...]) points to uninitialised byte(s) 2448137:==2448137== at 0x4D6FDDD: __writev (writev.c:26) 2448137-==2448137== by 0x4D6FDDD: writev (writev.c:24) 2448137-==2448137== by 0x48A35F5: buffer_flush_available (buffer.c:431) 2448137-==2448137== by 0x48A3504: buffer_flush_all (buffer.c:237) 2448137-==2448137== by 0x495948: zserv_write (zserv.c:263) 2448137-==2448137== by 0x4904B7E: thread_call (thread.c:1681) 2448137-==2448137== by 0x48BD3E5: fpt_run (frr_pthread.c:308) 2448137-==2448137== by 0x4C61EA6: start_thread (pthread_create.c:477) 2448137-==2448137== by 0x4D78DEE: clone (clone.S:95) 2448137-==2448137== Address 0x720c3ce is 62 bytes inside a block of size 4,120 alloc'd 2448137:==2448137== at 0x483877F: malloc (vg_replace_malloc.c:307) 2448137-==2448137== by 0x48D2977: qmalloc (memory.c:110) 2448137-==2448137== by 0x48A30E3: buffer_add (buffer.c:135) 2448137-==2448137== by 0x48A30E3: buffer_put (buffer.c:161) 2448137-==2448137== by 0x49591B: zserv_write (zserv.c:256) 2448137-==2448137== by 0x4904B7E: thread_call (thread.c:1681) 2448137-==2448137== by 0x48BD3E5: fpt_run (frr_pthread.c:308) 2448137-==2448137== by 0x4C61EA6: start_thread (pthread_create.c:477) 2448137-==2448137== by 0x4D78DEE: clone (clone.S:95) 2448137-==2448137== Uninitialised value was created by a stack allocation 2448137:==2448137== at 0x43E490: zserv_encode_vrf (zapi_msg.c:103)
Effectively we are sending `struct vrf_data` without ensuring
data has been properly initialized.
Donald Sharp [Sun, 31 Jan 2021 13:52:44 +0000 (08:52 -0500)]
ospf6d: prevent use after free
Valgrind reports:
2437395-==2437395== Invalid read of size 8 2437395:==2437395== at 0x40B610: ospf6_asbr_update_route_ecmp_path (ospf6_asbr.c:327) 2437395-==2437395== by 0x40BC7C: ospf6_asbr_lsa_add (ospf6_asbr.c:544) 2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829) 2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185) 2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320) 2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638) 2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681) 2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126) 2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232) 2437395-==2437395== Address 0x5c668a8 is 24 bytes inside a block of size 256 free'd 2437395:==2437395== at 0x48399AB: free (vg_replace_malloc.c:538) 2437395-==2437395== by 0x429027: ospf6_route_delete (ospf6_route.c:419) 2437395-==2437395== by 0x429027: ospf6_route_unlock (ospf6_route.c:460) 2437395-==2437395== by 0x429027: ospf6_route_remove (ospf6_route.c:887) 2437395-==2437395== by 0x40B343: ospf6_asbr_update_route_ecmp_path (ospf6_asbr.c:318) 2437395-==2437395== by 0x40BC7C: ospf6_asbr_lsa_add (ospf6_asbr.c:544) 2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829) 2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185) 2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320) 2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638) 2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681) 2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126) 2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232) 2437395-==2437395== Block was alloc'd at 2437395:==2437395== at 0x483AB65: calloc (vg_replace_malloc.c:760) 2437395-==2437395== by 0x48D2A32: qcalloc (memory.c:115) 2437395-==2437395== by 0x427CE4: ospf6_route_create (ospf6_route.c:402) 2437395-==2437395== by 0x40BA8A: ospf6_asbr_lsa_add (ospf6_asbr.c:490) 2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829) 2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185) 2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320) 2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638) 2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681) 2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126) 2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232)
ospfv3 loops through the ecmp routes to decide what to clean up. In some
situations the code free's up an existing route at the head of the list.
Cleaning the pointers in the list but never touching the original pointer.
In that case notice and update the old pointer.
Donatas Abraitis [Sun, 31 Jan 2021 14:20:36 +0000 (16:20 +0200)]
bgpd: Initialize bgp_notify.raw_data before passing to bgp_notify_receive()
``` 2523558-==2523558== 2523558-==2523558== Conditional jump or move depends on uninitialised value(s) 2523558:==2523558== at 0x47F242: bgp_notify_admin_message (bgp_debug.c:505) 2523558-==2523558== by 0x47F242: bgp_notify_print (bgp_debug.c:534) 2523558-==2523558== by 0x4BA9BC: bgp_notify_receive (bgp_packet.c:1905) 2523558-==2523558== by 0x4BA9BC: bgp_process_packet (bgp_packet.c:2602) 2523558-==2523558== by 0x4904B7E: thread_call (thread.c:1681) 2523558-==2523558== by 0x48CAA27: frr_run (libfrr.c:1126) 2523558-==2523558== by 0x474B1A: main (bgp_main.c:540) 2523558-==2523558== Uninitialised value was created by a stack allocation 2523558:==2523558== at 0x4BA33D: bgp_process_packet (bgp_packet.c:2529)
```
Donald Sharp [Sun, 31 Jan 2021 13:32:15 +0000 (08:32 -0500)]
eigrpd: Correctly set the mtu for eigrp packets sent
This version of eigrp pre-calculated the eigrp metric
to be a default of 1500 bytes, but unfortunately it
had entered the byte order wrong.
Modify the code to properly set the byte order
according to the eigrp rfc as well as actually
read in and transmit the mtu of the interface
instead of hard coding it to 1500 bytes.
Fixes: #7986 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Sat, 30 Jan 2021 19:31:47 +0000 (14:31 -0500)]
bfdd: Prevent unininited data transmittal
Valgrind reports:
2052866-==2052866== 2052866-==2052866== Syscall param sendmsg(msg.msg_name) points to uninitialised byte(s) 2052866:==2052866== at 0x49C8E13: sendmsg (sendmsg.c:28) 2052866-==2052866== by 0x11DC08: bp_udp_send (bfd_packet.c:823) 2052866-==2052866== by 0x11DD76: ptm_bfd_echo_snd (bfd_packet.c:179) 2052866-==2052866== by 0x114C2D: ptm_bfd_echo_xmt_TO (bfd.c:469) 2052866-==2052866== by 0x114C2D: ptm_bfd_echo_start (bfd.c:498) 2052866-==2052866== by 0x114C2D: bs_echo_timer_handler (bfd.c:1199) 2052866-==2052866== by 0x11E478: bfd_recv_cb (bfd_packet.c:702) 2052866-==2052866== by 0x4904846: thread_call (thread.c:1681) 2052866-==2052866== by 0x48CB4DF: frr_run (libfrr.c:1126) 2052866-==2052866== by 0x113044: main (bfdd.c:403) 2052866-==2052866== Address 0x1ffefff3e8 is on thread 1's stack
In ptm_bfd_echo_snd, for the v4 case we were memsetting the v6 memory
then setting the v4 memory. Just fix it.
Donald Sharp [Sat, 30 Jan 2021 19:13:34 +0000 (14:13 -0500)]
ospfd: Prevent sending of uninited data to zebra
Valgrind reports: 2174600-==2174600== 2174600-==2174600== Syscall param write(buf) points to uninitialised byte(s) 2174600:==2174600== at 0x49C7FB3: write (write.c:26) 2174600-==2174600== by 0x48A4EA0: buffer_write (buffer.c:475) 2174600-==2174600== by 0x4915AD9: zclient_send_message (zclient.c:298) 2174600-==2174600== by 0x12DB97: ospf_ldp_sync_state_req_msg (ospf_ldp_sync.c:114) 2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_if_start (ospf_ldp_sync.c:160) 2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_ism_change (ospf_ldp_sync.c:339) 2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_ism_change (ospf_ldp_sync.c:332) 2174600-==2174600== by 0x12C6A2: hook_call_ospf_ism_change (ospf_ism.c:46) 2174600-==2174600== by 0x12C6A2: ism_change_state (ospf_ism.c:540) 2174600-==2174600== by 0x12C6A2: ospf_ism_event (ospf_ism.c:600) 2174600-==2174600== by 0x4904846: thread_call (thread.c:1681)
When we send the request structure we are sending the whole thing and the
interface name string has junk at the end. Not a big deal, but cleans
up valgrind going wumple on us.
projects / mirror / frr.git / log