svn commit: r272089 - head/sys/netpfil/ipfw

[Andrey V. Elsukov]

On 25.09.2014 15:07, Sean Bruno wrote:
> On Thu, 2014-09-25 at 09:18 +0400, Gleb Smirnoff wrote:
>> On Wed, Sep 24, 2014 at 07:40:23PM -0700, Adrian Chadd wrote:
>> A> Hm, I saw this from Kate on IRC. Did anyone figure out _where_ these
>> A> frames are coming from?
>> A> 
>> A> Just dropping them is cool, but I'd really like to see the contents of
>> A> the frames and what their origin is.
>> A> 
>> A> I'm worried that they're valid stack-generated frames..
>>
>> I agree on this. Fixing NULL pointer derefs with NULL check is not
>> always a right thing to do.
>> A> >
>> A> > Log:
>> A> >   Fix NULL pointer deref in ipfw when using dummynet at layer 2.
>> A> >   Drop packet if pkg->ifp is NULL, which is the case here.
>> A> >
>> A> >   ref. https://github.com/HardenedBSD/hardenedBSD
>> A> >   commit 4eef3881c64f6e3aa38eebbeaf27a947a5d47dd7
>> A> >
>> A> >   PR 193861 --  DUMMYNET LAYER2: kernel panic
>> A> >
>> A> >   in this case a kernel panic occurs. Hence, when we do not get an interface,
>> A> >   we just drop the packet in question.

> Ok, moving off to freebsd-net.  How should we proceded with debugging
> further?

Probably this can occurs when outgoing interface disappeared
(netgrapg/tun/tap/lagg/vlan/usb ethernet), but packets were not send yet
(delayed in the dummynet pipe). I think this is well known problem.

-- 
WBR, Andrey V. Elsukov