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
