BIRD 2.0.7 Segmentation fault when using receive limit
Hello, I'm getting a "Segmentation fault" error on BIRD 2.0.7 when I use 'receive limit X'. I've got the error when using either 'action block' or 'action disable'. In the same scenario, if I change the config to use 'import limit X' everything works fine. The error happens as soon as the daemon receives the first "extra" route from its peer (in the example, the 5th route while the limit is 4). Output of '-d -f' can be found at the bottom of this msg. If the number of routes received from the peer is equal to the limit, the issue is not hit. I was able to consistently reproduce what I've mentioned above using the following config on a Docker container based on Debian 10.1 (Linux f484b919cd3a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020 x86_64 GNU/Linux - Dockerfile can be found here https://github.com/pierky/dockerfiles/blob/master/bird/2.0.7/Dockerfile). BIRD 1.6.8 works fine. Thanks. Pier Carlo router id 192.0.2.2; define rs_as = 999; log "/var/log/bird.log" all; log syslog all; debug protocols { states, routes, filters, interfaces, events }; timeformat base iso long; timeformat log iso long; timeformat protocol iso long; timeformat route iso long; protocol device {}; ipv4 table master4 sorted; ipv6 table master6 sorted; filter receive_from_AS1_1 { if !(source = RTS_BGP ) then reject "source != RTS_BGP - REJECTING ", net; if !(net.type = NET_IP4) then reject "AFI not enabled for this peer - REJECTING ", net; accept; } protocol bgp AS1_1 { local as 999; neighbor 192.0.2.11 as 1; rs client; passive on; ttl security off; interpret communities off; # --------------------------------------- ipv4 { table master4; secondary; receive limit 4 action block; import table on; import keep filtered on; import filter receive_from_AS1_1; export none; # --------------------------------------- }; } Output of '-d -f': root@f484b919cd3a:~# bird -c /etc/bird/bird.conf -d -f bird: device1: Initializing bird: AS1_1: Channel ipv4 connected to table master4 bird: AS1_1: Initializing bird: device1: Starting bird: device1: Scanning interfaces bird: device1: State changed to up bird: AS1_1: Starting bird: AS1_1: State changed to start bird: Started bird: AS1_1: Started bird: AS1_1: Incoming connection from 192.0.2.11 (port 49457) accepted bird: AS1_1: BGP session established bird: AS1_1: State changed to up bird: AS1_1 > added [best] 1.0.1.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.1.0/24 unicast bird: AS1_1 > added [best] 1.0.3.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.3.0/24 unicast bird: AS1_1 > added [best] 1.0.2.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.2.0/24 unicast bird: AS1_1 > added [best] 1.0.5.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.5.0/24 unicast bird: Protocol AS1_1 hits route receive limit (4), action: disable Segmentation fault
Hello, was anyone else able to reproduce this issue? I've been able to reproduce it also using the code from master. I paste some more info here, I hope they'll be useful to troubleshoot it. Thanks Pier Carlo GDB: bird: Started bird: AS1_1: Started bird: AS1_1: Incoming connection from 192.0.2.11 (port 44145) accepted bird: AS1_1: BGP session established bird: AS1_1: State changed to up bird: AS1_1 > added [best] 1.0.1.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.1.0/24 unicast bird: AS1_1 > added [best] 1.0.3.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.3.0/24 unicast bird: AS1_1 > added [best] 1.0.2.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.2.0/24 unicast bird: AS1_1 > added [best] 1.0.5.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.5.0/24 unicast bird: Protocol AS1_1 hits route receive limit (4), action: disable Program received signal SIGSEGV, Segmentation fault. 0x000055b5c20d8eb1 in net_format (N=0xcdcdcdcdcdcdcde5, buf=0x7ffc6c8d0570 "", buflen=257) at lib/net.c:82 82 switch (n->n.type) (gdb) (gdb) (gdb) bt #0 0x000055b5c20d8eb1 in net_format (N=0xcdcdcdcdcdcdcde5, buf=0x7ffc6c8d0570 "", buflen=257) at lib/net.c:82 #1 0x000055b5c20da380 in bvsnprintf (buf=0x7ffc6c8d0770 "AS1_1 > ignored [limit] \b", size=1000, fmt=0x55b5c218e478 "N %s", args=0x7ffc6c8d0be0) at lib/printf.c:246 #2 0x000055b5c20db3af in buffer_vprint (buf=0x7ffc6c8d0ba0, fmt=0x55b5c218e46e "%s %c %s %N %s", args=0x7ffc6c8d0be0) at lib/printf.c:531 #3 0x000055b5c2161d0a in vlog (class=2, msg=0x55b5c218e46e "%s %c %s %N %s", args=0x7ffc6c8d0be0) at sysdep/unix/log.c:219 #4 0x000055b5c2161e06 in log_msg (msg=0x55b5c218e46e "%s %c %s %N %s") at sysdep/unix/log.c:244 #5 0x000055b5c20f7d35 in rte_trace (p=0x55b5c3a026a0, e=0x55b5c3a15598, dir=62, msg=0x55b5c218e5f5 "ignored [limit]") at nest/rt-table.c:555 #6 0x000055b5c20f7d79 in rte_trace_in (flag=4, p=0x55b5c3a026a0, e=0x55b5c3a15598, msg=0x55b5c218e5f5 "ignored [limit]") at nest/rt-table.c:562 #7 0x000055b5c20fbf06 in rte_update_in (c=0x55b5c3a029e0, n=0x7ffc6c8d0e30, new=0x55b5c3a15598, src=0x55b5c3a0a5c0) at nest/rt-table.c:2493 #8 0x000055b5c211984d in rte_update3 (c=0x55b5c3a029e0, n=0x7ffc6c8d0e30, new=0x55b5c3a15598, src=0x55b5c3a0a5c0) at ./nest/protocol.h:638 #9 0x000055b5c211d17a in bgp_rte_update (s=0x7ffc6c8d0f90, n=0x7ffc6c8d0e30, path_id=0, a0=0x7ffc6c8d0e60) at proto/bgp/packets.c:1331 #10 0x000055b5c211d6e9 in bgp_decode_nlri_ip4 (s=0x7ffc6c8d0f90, pos=0x55b5c3a0d33f "", len=0, a=0x7ffc6c8d0e60) at proto/bgp/packets.c:1479 #11 0x000055b5c211f2b5 in bgp_decode_nlri (s=0x7ffc6c8d0f90, afi=65537, nlri=0x55b5c3a0d32b "\030\001", len=20, ea=0x55b5c3a132b0, nh=0x55b5c3a0d327 "\300", nh_len=4) at proto/bgp/packets.c:2410 #12 0x000055b5c211f743 in bgp_rx_update (conn=0x55b5c3a028a8, pkt=0x55b5c3a0d300 '\377' <repeats 16 times>, len=63) at proto/bgp/packets.c:2505 #13 0x000055b5c2120b75 in bgp_rx_packet (conn=0x55b5c3a028a8, pkt=0x55b5c3a0d300 '\377' <repeats 16 times>, len=63) at proto/bgp/packets.c:3097 #14 0x000055b5c2120d02 in bgp_rx (sk=0x55b5c3a0d1b0, size=63) at proto/bgp/packets.c:3142 #15 0x000055b5c215dd41 in call_rx_hook (s=0x55b5c3a0d1b0, size=63) at sysdep/unix/io.c:1796 #16 0x000055b5c215e116 in sk_read (s=0x55b5c3a0d1b0, revents=1) at sysdep/unix/io.c:1884 #17 0x000055b5c215f028 in io_loop () at sysdep/unix/io.c:2342 #18 0x000055b5c2164109 in main (argc=5, argv=0x7ffc6c8d13d8) at sysdep/unix/main.c:923 valgrind: root@c8fa0d485dcd:~# valgrind --leak-check=yes bird -c /etc/bird/bird.conf -d -f ==270== Memcheck, a memory error detector ==270== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==270== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==270== Command: bird -c /etc/bird/bird.conf -d -f ==270== ... bird: AS1_1: Started bird: AS1_1: Incoming connection from 192.0.2.11 (port 59019) accepted bird: AS1_1: BGP session established bird: AS1_1: State changed to up bird: AS1_1 > added [best] 1.0.1.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.1.0/24 unicast bird: AS1_1 > added [best] 1.0.3.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.3.0/24 unicast bird: AS1_1 > added [best] 1.0.2.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.2.0/24 unicast bird: AS1_1 > added [best] 1.0.5.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.5.0/24 unicast bird: Protocol AS1_1 hits route receive limit (4), action: disable ==270== Invalid read of size 1 ==270== at 0x159EB1: net_format (net.c:82) ==270== by 0x15B37F: bvsnprintf (printf.c:246) ==270== by 0x15C3AE: buffer_vprint (printf.c:531) ==270== by 0x1E2D09: vlog (log.c:219) ==270== by 0x1E2E05: log_msg (log.c:244) ==270== by 0x178D34: rte_trace (rt-table.c:555) ==270== by 0x178D78: rte_trace_in (rt-table.c:562) ==270== by 0x17CF05: rte_update_in (rt-table.c:2493) ==270== by 0x19A84C: rte_update3 (protocol.h:638) ==270== by 0x19E179: bgp_rte_update (packets.c:1331) ==270== by 0x19E6E8: bgp_decode_nlri_ip4 (packets.c:1479) ==270== by 0x1A02B4: bgp_decode_nlri (packets.c:2410) ==270== Address 0xcdcdcdcdcdcdcde5 is not stack'd, malloc'd or (recently) free'd ==270== ==270== ==270== Process terminating with default action of signal 11 (SIGSEGV) ==270== General Protection Fault ==270== at 0x159EB1: net_format (net.c:82) ==270== by 0x15B37F: bvsnprintf (printf.c:246) ==270== by 0x15C3AE: buffer_vprint (printf.c:531) ==270== by 0x1E2D09: vlog (log.c:219) ==270== by 0x1E2E05: log_msg (log.c:244) ==270== by 0x178D34: rte_trace (rt-table.c:555) ==270== by 0x178D78: rte_trace_in (rt-table.c:562) ==270== by 0x17CF05: rte_update_in (rt-table.c:2493) ==270== by 0x19A84C: rte_update3 (protocol.h:638) ==270== by 0x19E179: bgp_rte_update (packets.c:1331) ==270== by 0x19E6E8: bgp_decode_nlri_ip4 (packets.c:1479) ==270== by 0x1A02B4: bgp_decode_nlri (packets.c:2410) ==270== ==270== HEAP SUMMARY: ==270== in use at exit: 156,337 bytes in 589 blocks ==270== total heap usage: 867 allocs, 278 frees, 406,303 bytes allocated ==270== ==270== LEAK SUMMARY: ==270== definitely lost: 0 bytes in 0 blocks ==270== indirectly lost: 0 bytes in 0 blocks ==270== possibly lost: 0 bytes in 0 blocks ==270== still reachable: 156,337 bytes in 589 blocks ==270== suppressed: 0 bytes in 0 blocks ==270== Reachable blocks (those to which a pointer was found) are not shown. ==270== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==270== ==270== For counts of detected and suppressed errors, rerun with: -v ==270== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault On Sat, 24 Oct 2020 at 16:17, Pier Carlo Chiodi <pierky@pierky.com> wrote:
Hello,
I'm getting a "Segmentation fault" error on BIRD 2.0.7 when I use 'receive limit X'. I've got the error when using either 'action block' or 'action disable'. In the same scenario, if I change the config to use 'import limit X' everything works fine.
The error happens as soon as the daemon receives the first "extra" route from its peer (in the example, the 5th route while the limit is 4). Output of '-d -f' can be found at the bottom of this msg. If the number of routes received from the peer is equal to the limit, the issue is not hit.
I was able to consistently reproduce what I've mentioned above using the following config on a Docker container based on Debian 10.1 (Linux f484b919cd3a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020 x86_64 GNU/Linux - Dockerfile can be found here https://github.com/pierky/dockerfiles/blob/master/bird/2.0.7/Dockerfile).
BIRD 1.6.8 works fine.
Thanks.
Pier Carlo
router id 192.0.2.2; define rs_as = 999;
log "/var/log/bird.log" all; log syslog all; debug protocols { states, routes, filters, interfaces, events };
timeformat base iso long; timeformat log iso long; timeformat protocol iso long; timeformat route iso long;
protocol device {};
ipv4 table master4 sorted; ipv6 table master6 sorted;
filter receive_from_AS1_1 { if !(source = RTS_BGP ) then reject "source != RTS_BGP - REJECTING ", net;
if !(net.type = NET_IP4) then reject "AFI not enabled for this peer - REJECTING ", net;
accept; }
protocol bgp AS1_1 {
local as 999; neighbor 192.0.2.11 as 1; rs client;
passive on; ttl security off; interpret communities off;
# --------------------------------------- ipv4 { table master4;
secondary;
receive limit 4 action block;
import table on; import keep filtered on; import filter receive_from_AS1_1;
export none;
# --------------------------------------- }; }
Output of '-d -f':
root@f484b919cd3a:~# bird -c /etc/bird/bird.conf -d -f bird: device1: Initializing bird: AS1_1: Channel ipv4 connected to table master4 bird: AS1_1: Initializing bird: device1: Starting bird: device1: Scanning interfaces bird: device1: State changed to up bird: AS1_1: Starting bird: AS1_1: State changed to start bird: Started bird: AS1_1: Started bird: AS1_1: Incoming connection from 192.0.2.11 (port 49457) accepted bird: AS1_1: BGP session established bird: AS1_1: State changed to up bird: AS1_1 > added [best] 1.0.1.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.1.0/24 unicast bird: AS1_1 > added [best] 1.0.3.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.3.0/24 unicast bird: AS1_1 > added [best] 1.0.2.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.2.0/24 unicast bird: AS1_1 > added [best] 1.0.5.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.5.0/24 unicast bird: Protocol AS1_1 hits route receive limit (4), action: disable Segmentation fault
On Sun, Nov 01, 2020 at 02:36:40PM +0100, Pier Carlo Chiodi wrote:
Hello, was anyone else able to reproduce this issue? I've been able to reproduce it also using the code from master.
Hello Thanks for the bugreport and backtrace. Now i have an idea what causes the issue and how to reproduce it (it is specific to using import table together with debug logs enabled). Will send patch soon. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Sun, Nov 01, 2020 at 02:36:40PM +0100, Pier Carlo Chiodi wrote:
Hello, was anyone else able to reproduce this issue? I've been able to reproduce it also using the code from master.
I paste some more info here, I hope they'll be useful to troubleshoot it.
Thanks
Hi Sorry for late answer, Here is the patch. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi, thanks a lot, I've managed to test it and I confirm that works fine. Can you confirm whether it will be included in 2.0.8? Thanks, Pier Carlo On Sun, 15 Nov 2020 at 16:07, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sun, Nov 01, 2020 at 02:36:40PM +0100, Pier Carlo Chiodi wrote:
Hello, was anyone else able to reproduce this issue? I've been able to reproduce it also using the code from master.
I paste some more info here, I hope they'll be useful to troubleshoot it.
Thanks
Hi
Sorry for late answer, Here is the patch.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Wed, Nov 18, 2020 at 09:05:57PM +0100, Pier Carlo Chiodi wrote:
Hi,
thanks a lot, I've managed to test it and I confirm that works fine.
Can you confirm whether it will be included in 2.0.8?
Yes -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Ondrej Zajicek -
Pier Carlo Chiodi