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).

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@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."
diff --git a/filter/f-inst.c b/filter/f-inst.c
index 58717d55..91fd7e32 100644
--- a/filter/f-inst.c
+++ b/filter/f-inst.c
@@ -922,8 +922,8 @@
     uint retpos = fstk->vcnt;
 
     /* Drop every sub-block including ourselves */
-    while ((fstk->ecnt-- > 0) && !(fstk->estk[fstk->ecnt].emask & FE_RETURN))
-      ;
+    do fstk->ecnt--;
+    while ((fstk->ecnt > 0) && !(fstk->estk[fstk->ecnt].emask & FE_RETURN));
 
     /* Now we are at the caller frame; if no such, try to convert to accept/reject. */
     if (!fstk->ecnt)

Reply via email to