If you have a very large number of large communities whose
string length happened to be greater than BUFSIZ FRR's bgpd
would crash. This is because bgpd would write beyond
the end of the string.
Originally the code auto-calculated the string size appropriately
but commit ed0e57e3f0 modified
the string length to be a hard coded BUFSIZ. When a route-map
like this is added:
route-map LARGE-OUT permit 10
set large-community 4635:0:0 4635:1:906 4635:1:2906 4635:1:4515 4635:1:4594 4635:1:4641 4635:1:4760 4635:1:7979 4635:1:9253 4635:1:9293 4635:1:9304 4635:1:9908 4635:1:13335 4635:1:16265 4635:1:17924 4635:1:18013 4635:1:20940 4635:1:22822 4635:1:24429 4635:1:24482 4635:1:32590 4635:1:32934 4635:1:36692 4635:1:38008 4635:1:38819 4635:1:41378 4635:1:45753 4635:1:46489 4635:1:49544 4635:1:51847 4635:1:54574 4635:1:54994 4635:1:55720 4635:1:56059 4635:1:57724 4635:1:65021 4635:1:134823 4635:1:136907 4635:1:146961 24115:0:24115 24115:1:906 24115:1:2906 24115:1:4515 24115:1:4594 24115:1:4641 24115:1:4760 24115:1:7979 24115:1:9253 24115:1:9293 24115:1:9304 24115:1:9908 24115:1:13335 24115:1:16265 24115:1:17924 24115:1:18013 24115:1:20940 24115:1:22822 24115:1:24429 24115:1:24482 24115:1:32590 24115:1:32934 24115:1:36692 24115:1:38008 24115:1:38819 24115:1:41378 24115:1:45753 24115:1:46489 24115:1:49544 24115:1:51847 24115:1:54574 24115:1:54994 24115:1:55720 24115:1:56059 24115:1:57724 24115:1:65021 24115:1:134823 24115:1:136907 24115:1:100000 24115:1:100001 24115:1:100002
exit
BGP would have issues and crash.
Modify the code to correctly determine the string length of the communities
and to also double check if the string has an alias and ensure that the
string is still sufficiently large enough. If not auto size it again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Before:
```
spine1-debian-11(config-route-map)# bgp community alias 65001:65001 test1
spine1-debian-11(config)# route-map rm permit 10
spine1-debian-11(config-route-map)# set community 65001:65001
% Malformed communities attribute
```
After:
```
spine1-debian-11(config)# bgp community alias 65001:65001 test1
spine1-debian-11(config)# route-map rm permit 10
spine1-debian-11(config-route-map)# set community 65001:65001
spine1-debian-11(config-route-map)#
```
Same for large-communities.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
the realloc man page:
If ptr is NULL, then the call is equivalent to malloc(size)
This should be sufficient for our needs to not have to have
XMALLOC and XREALLOC
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Show alias name instead of numerical value in `show bgp <prefix>. E.g.:
```
root@exit1-debian-9:~/frr# vtysh -c 'sh run' | grep 'bgp community alias'
bgp community alias 65001:123 community-1
bgp community alias 65001:123:1 lcommunity-1
root@exit1-debian-9:~/frr#
```
```
exit1-debian-9# sh ip bgp 172.16.16.1/32
BGP routing table entry for 172.16.16.1/32, version 21
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
65030
192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (172.16.16.1)
Origin incomplete, metric 0, valid, external, best (Neighbor IP)
Community: 65001:12 65001:13 community-1 65001:65534
Large Community: lcommunity-1 65001:123:2
Last update: Fri Apr 16 12:51:27 2021
exit1-debian-9#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
`lcommunity_gettoken` expects a space-delimeted list of 0 or more large
communities. `lcommunity_list_valid` can perform this check.
`lcommunity_list_valid` now validates large community lists more
accurately based on the following condition: Each quantity in a standard bgp
large community must:
1. Contain at least one digit
2. Fit within 4 octets
3. Contain only digits unless the lcommunity is "expanded"
4. Contain a valid regex if the lcommunity is "expanded"
Moreover we validate that each large community list contains exactly 3
such values separated by a single colon each.
One quirk of our validation which is worth documenting is:
```
bgp large-community-list standard test2 permit 1:c:3
bgp large-community-list expanded test1 permit 1:c:3
```
The first line will throw an error complaining about a "malformed community-list
value". The second line will be accepted because the each value is each treated as
a regex when matching large communities, it simply will never match anything so
it's rather useless.
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
Community attributes might have been removed by an inbound route map, so we
should check to ensure they still exist before trying to free them.
This fixes a segfault described in issue #6345.
Signed-off-by: Josh Cox <josh.cox@pureport.com>
More second order effects of cleaning up rn usage
in bgp. Sprinkle the fairy const's all over the place.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Some were converted to bool, where true/false status is needed.
Converted to void only those, where the return status was only false or true.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
It's been a year search and destroy.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Spaces were not being accounted for in the heap buffer sizing, leading
to a heap buffer overflow when encoding large communities to their
string representations.
This patch also uses safer functions to do the encoding instead of
pointer math.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
While configuring aggregate route prepare the hash table first,
then prepare the aggregated lcomm value and then do the unique
sort once for large community.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
The CLI to configure the standard format large-communities attribute
accepts regular expressions as well.
For ex., the below configuration is accepted.
"bgp large-community-list standard TEST permit 1:1 100:*"
The code to parse the large-communities does identify the configuration
as invalid however, error returned isn't processed.
The code has to be modified to handle the error.
Signed-off-by: NaveenThanikachalam nthanikachal@vmware.com
The correct cast for these is (unsigned char), because "char" could be
signed and thus have some negative value. isalpha & co. expect an int
arg that is positive, i.e. 0-255. So we need to cast to (unsigned char)
when calling any of these.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
It doesn't make much sense for a hash function to modify its argument,
so const the hash input.
BGP does it in a couple places, those cast away the const. Not great but
not any worse than it was.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
With this commit:
1) The code to manage the large-communities attribute of the routes that are
aggregatable under a configured aggregate-address is introduced.
2) The code to compute the aggregate-route's large-communities attribute is
introduced.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Like community_cmp() and ecommunity_cmp(), the lcommunity_cmp() function
also needs to handle NULL pointers for correct operation.
Without this fix, bgpd can crash when entering the following commands:
vtysh -c "configure terminal" -c "ip large-community-list standard WORD deny"
vtysh -c "configure terminal" -c "no ip large-community-list expanded WORD"
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The ->hash_cmp and linked list ->cmp functions were sometimes
being used interchangeably and this really is not a good
thing. So let's modify the hash_cmp function pointer to return
a boolean and convert everything to use the new syntax.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit removes various parts of the bgpd implementation code which
are unused/useless, e.g. unused functions, unused variable
initializations, unused structs, ...
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation of building JSON output is greatly different
for large communities compared to standard communities. This is mainly
noticeable by the missing 'list' attribute, which usually offers an
array of all communities present on a BGP route.
This commit adds the missing functionality of properly returning a
'list' attribute in JSON output and also tries a similar approach like
the standard communities are using to implement this feature.
Additionally, the 'format' specifier has been completely removed from
large communities string/JSON rendering, as the official RFC8092 specifies that
there is only one canonical representation:
> The canonical representation of BGP Large Communities is three
> separate unsigned integers in decimal notation in the following
> order: Global Administrator, Local Data 1, Local Data 2. Numbers
> MUST NOT contain leading zeros; a zero value MUST be represented with
> a single zero. Each number is separated from the next by a single
> colon. For example: 64496:4294967295:2, 64496:0:0.
As the 'format' specifier has not been used/checked and only one
canonical representation exists per today, there was no reason to keep
the 'format' parameter in the function signature.
Last but not least, the struct attribute 'community_entry.config' is no
longer being used for large communities and instead 'lcommunity_str' is
being called to maintain a similar approach to standard communities.
As a side effect, this also fixed a memory leak inside 'community_entry_free'
which did not free the allocated memory for the 'config' attribute when
dealing with a large community.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
1) Add hash names to all hash_create calls
2) Fix community_hash, ecommunity_hash and lcommunity_hash key
creation
3) Fix output of community and lcommunity iterators( why would
we want to see the memory location of the backet? ).
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(to match surrounding code)
"git diff -w" should be almost empty.
Copyright edited to say FRR, this is not GNU Zebra :)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Ensure that we don't leak any memory on shutdown.
Since the bgp_lcommunity.c file mirrors bgp_ecommunity.c
Add the same code for shutdown that ecommunity has.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
