In some email I received from Darren Reed, sie wrote:
> 
> Part of the problem, as I see it, with the code that calls bpf_mtap()
> from things like if_tun.c is that the mbuf passed is not properly
> initialised and as it is a local variable, picking up whatever junk
> is on the stack, i.e.:
> ....
>                 struct mbuf m;
>                 u_int32_t af = dst->sa_family;
> 
>                 m.m_next = m0;
>                 m.m_len = sizeof(af);
>                 m.m_data = (char *)⁡
> 
>                 bpf_mtap(ifp->if_bpf, &m);
> ....

To each of 'these', I'm planning on adding this:

                  /* XXX mbufs are not usually on the stack ... */
                  m.m_type = -1;
                  m.m_flags = 0;

Before I *do* this, does anyone want to pipe up and say "bad boy, use
MGET() to get a _real_ mbuf for this" ?

The issue here is that if bpf_mtap() and further into the BPF code
ever expect the pointer it gets passed to be a _real_ mbuf and tries
to do things with it, it could run into trouble.  The tradeoff is
speed.  I'm quite happy to put a large comment in bpf.c saying
something along the lines of "not all mbufs are equal and don't
ever try to alter the mbuf chain in here".

Comments ?

Darren