Re: ipfw: LOR/panic with uid rules

On Fri, 26 Sep 2008, Stefan Ehmann wrote:

> > > #10 0xc07eccd6 in _rw_rlock (rw=0xc0e5acec, file=0xc103ceed 
> > > "/usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c", line=2020) at 
> > > /usr/src/sys/kern/kern_rwlock.c:283
> > >
> > > #11 0xc103b92a in ipfw_chk (args=0xc47328a8) at 
> > > /usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2020
> >
> > This surprises me -- can in principle we've passed down 'inp' so there 
> > should be no need to look it up. In higher frames, 'inp' is definitely 
> > non-NULL, so what happened here? Could you print out the values of the 
> > local variables in the check_uidgid() frame? Especially, 'inp' and 
> > 'lookup'?
> 
> Something seems to be broken or I'm doing something wrong. I can't access
> the locals:

Dear Stefan:

Could you update to ip_fw2.c:1.195?  I've fixed an issue there that caused 
ipfw to look up the inpcb even thought it was passed down in the case that a 
TCP connection was in TIMEWAIT:

   revision 1.195
   date: 2008/09/27 19:28:28;  author: rwatson;  state: Exp;  lines: +2 -1
   SVN rev 183418 on 2008-09-27 19:28:28Z by rwatson

   When an inpcb doesn't have a socket but the inpcb is passed to ipfw
   in the transmit path, such as TCPS_TIMEWAIT, fail the credential
   extraction immediately rather than acquiring locks and looking up
   the inpcb on the global lists in order to reach the conclusion that
   the credential extraction has failed.

   This is more efficient, but more importantly, it avoids lock
   recursion on the inpcbinfo, which is no longer allowed with rwlocks.
   This appears to have been responsible for at least two reported
   panics.

   MFC after:      3 days
   Reported by:    ganbold

Robert N M Watson
Computer Laboratory
University of Cambridge