On 28/12/2020 15:06, Ondrej Zajicek wrote:
On Mon, Dec 28, 2020 at 04:29:25AM +0100, Ondrej Zajicek wrote:
On Sun, Dec 27, 2020 at 09:58:57PM +0100, Damian Zaremba wrote:
Hi,
It appears there is a segfault in the route specific filters, this was initially observed during a `configure`, but appears to be easily reproducible with startup config.
protocol static { ipv4 {}; route 192.0.2.0/24 via "lo" { return false; }; } Hi
Thanks for the bugreport, seems to me that the issue is related to 'return' at the top-level of the filter, it causes the crash also in regular filter. Will check that. Hi
Attached patch fixes the issue. Top-level return now behaves like accept/reject and not crash BIRD. But route-specific filters in static protocol cannot really 'reject' route, they can just modify attributes (so reject / 'return false' is ignored).
Hi, Thanks for the fast response and fix - I can confirm that is working as expected on my side. Unfortunately I did discover another segfault (testing from current master) which appears to be due to `net` being uninitialised in the route specific filters; Minimal reproduction config; ``` router id 192.0.2.0; protocol device {} protocol static { ipv4 {}; route 192.0.2.0/24 via "lo" { print net; }; } ``` Backtrace; ``` (gdb) r Starting program: /bird/bird -c /etc/bird/bird.conf -d warning: Error disabling address space randomization: Operation not permitted [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x0000000000445872 in net_format (N=0xcdcdcdcdcdcdcde5, buf=0x7fff514b7ae0 "", buflen=257) at lib/net.c:82 82 switch (n->n.type) (gdb) bt #0 0x0000000000445872 in net_format (N=0xcdcdcdcdcdcdcde5, buf=0x7fff514b7ae0 "", buflen=257) at lib/net.c:82 #1 0x0000000000446db9 in bvsnprintf (buf=0x7fff514b8380 "\036", size=1024, fmt=0x4fb373 "N", args=0x7fff514b7c20) at lib/printf.c:246 #2 0x000000000044816b in buffer_print (buf=0x7fa22cfeb758, fmt=0x4fb372 "%N") at lib/printf.c:547 #3 0x0000000000431f17 in val_format (v=0x7fa22cfeb780, buf=0x7fa22cfeb758) at filter/data.c:563 #4 0x0000000000427df9 in interpret (fs=0x7fa22cfeb730, line=0xb46090, val=0x7fff514b8bc0) at filter/f-inst.c:478 #5 0x000000000042fecc in f_eval_rte (expr=0xb46090, rte=0x7fff514b8d08, tmp_pool=0xb537f0) at filter/filter.c:357 #6 0x00000000004c1260 in static_announce_rte (p=0xb4bd70, r=0xb45f00) at proto/static/static.c:109 #7 0x00000000004c172c in static_add_rte (p=0xb4bd70, r=0xb45f00) at proto/static/static.c:231 #8 0x00000000004c2083 in static_start (P=0xb4bd70) at proto/static/static.c:449 #9 0x0000000000459c03 in proto_rethink_goal (p=0xb4bd70) at nest/proto.c:1220 #10 0x0000000000459a6e in protos_commit (new=0xb40170, old=0x0, force_reconfig=0, type=1) at nest/proto.c:1179 #11 0x0000000000423093 in config_do_commit (c=0xb40170, type=1) at conf/conf.c:271 #12 0x000000000042325a in config_commit (c=0xb40170, type=1, timeout=0) at conf/conf.c:361 #13 0x00000000004d27f9 in main (argc=4, argv=0x7fff514b9018) at sysdep/unix/main.c:912 ``` This was originally triggered in a function call that used an `if net ~ set` operation, so while the above config doesn't really make practical sense it's the smallest filter I could make to repeatedly trigger the issue. I suspect my interpretation of the per-route filter expression support is a little too liberal compared to the intended usage. For now I will go back to applying filtering on a pipe from one "static table" into another "static table", which should solve my needs, but I wanted to highlight the second crash as it's not ideal behavior. Many Thanks - Damian