kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives

[Ermal Luçi]

2012/4/16 Gleb Smirnoff <glebius at freebsd.org>:
> On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
> T>  On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
> T>  T>    I have a vague suspicion on what is happening. Your description of
> T>  T>  the problem looks like if a packet processing in the kernel has entered
> T>  T>  an endless loop.
> T>  T>
> T>  T>    Looking at pf_route() I see such possibility. From OpenBSD we have
> T>  T>  this protection against endless looping:
> T>  T>
> T>  T>          if ((*m)->m_pkthdr.pf.routed++ > 3) {
> T>  T>                  m0 = *m;
> T>  T>                  *m = NULL;
> T>  T>                  goto bad;
> T>  T>          }
> T>  T>
> T>  T>  In our code this transforms to:
> T>  T>
> T>  T>          if (pd->pf_mtag->routed++ > 3) {
> T>  T>                  m0 = *m;
> T>  T>                  *m = NULL;
> T>  T>                  goto bad;
> T>  T>          }
> T>  T>
> T>  T>  The root difference between storing the tag on mbuf and on pfdesc
> T>  T>  is that we lose pfdesc, and thus the tag, when we enter pf_test()
> T>  T>  recursively. And pf_route() does this recursion:
> T>  T>
> T>  T>          if (oifp != ifp) {
> T>  T>                  if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
> T>  T>                          goto bad;
> T>  T>          ....
> T>
> T>  On second look I see that my suspicion may not be true. In the
> T>  beginning of pf_test() we do pf_get_mtag() which preserves already
> T>  present tag if there is one.
>
> Further investigation showed that problem exist when route applied
> ends in lo0, and packet passes to if_simloop(). There all mtags are
> stripped from the mbuf, including the pf mtag. Then packet is again
> processed by ip_input() again entering pf(4), if it again matches
> a routing rule, then we got an endless loop.
>
> We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
>

That seems like the best fix for this case.

> --
> Totus tuus, Glebius.
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"



-- 
Ermal