On Sunday 06 July 2008, Nicolas Thery wrote: > 2008/7/5 Nicolas Thery <[EMAIL PROTECTED]>: > > It looks like so_pru_ctloutput() passes an invalid sopt_val to > > kfree(). This code was changed > > recently: > > > > http://leaf.dragonflybsd.org/mailarchive/commits/2008-06/msg00123.html > > > > There is some pointer arithmetic on sopt_val in soopt_mcopyout() that > > may cause the panic you > > observe. sopt_val ends up pointing past the data copied from the > > mbuf. Maybe this is > > intentional as the code is old (imported straight from fbsd 4 and is > > still in fbsd head). This > > would allow to append more data later on. On the other hand, maybe > > that's a bug. Only a > > networking savvy person could say.
I'm not a networking savvy person (working on it) but having spent some time on ctloutput functions lately it seems like an outright bug to me. Even if some code was depending on it, this behavior violates POLA and would need to go anyway. > Forget this, soopt_mcopyout() is called during getsockopt() but the > crash ocurred during setsockopt()... Right, but soopt_mcopyin() does the exact same thing ;) Nice catch. Things seem to work here with these two changes (+ SOPTF_KVA), wanna commit it? Aggelos
