Re: netfilter QUEUE target and packet socket interactions buggy or not

[Eric Leblond <eric@inl.fr>]

Le vendredi 16 septembre 2005 à 16:38 +0300, Nuutti Kotivuori a écrit :
> Just to reiterate, I still haven't been able to reproduce this on the
> mainline kernel, only with RHEL 4 kernels. So if you want to skip
> this, that's fine.

It remembers me the problem I had with RHEL4 :

https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020505.html

I did not have to study the problem in detail but it may be helpful for
your current problem.

BR,

> 
> Patrick McHardy wrote:
> > Nuutti Kotivuori wrote:
> >>
> >> Appended here is a backtrace with the tg3 driver. Also, it seems that
> >> the bug cannot be reproduced with uniprocessor, only SMP.
> >>
> >> Unable to handle kernel NULL pointer dereference at virtual address 00000018
> >
> > This means inode->i_security was NULL. AFAICT it is only set to NULL in
> > inode_free_security() when the inode is freed. This shouldn't happen
> > while the packet is queued since the skb should hold a reference to
> > the socket on the output path. So it could be some protocol forgetting
> > to increase the refcnt when taking a reference. What kind of packet
> > is this? And what kernel version are you running? Until recently
> > ip_conntrack did some fiddling with skb->sk which could lead to
> > a packet on the output path with skb->sk set but no reference taken.
> 
> I finally managed to add enough debug dumps to find out what packet it
> is. It is a TCP FIN,ACK packet, going outwards, originating from the
> machine which crashes. It seems that the TCP FIN,ACK packet get sent
> outwards, is caught by the QUEUE target in netfilter, goes to
> userspace, comes back, continues onwards, gets rejected by the filter
> rule in packet socket and then hits the selinux outbound handler and
> at that point, the socket has been freed, so it crashes. Atleast this
> is my understanding at the moment. This all is very confusing, though.
> 
> -- Naked
>