BIRD 2.0.7 segfault in route filters

[Damian Zaremba]

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