Re: [PATCH] tproxy: nf_tproxy_assign_sock() can handle tw sockets

From: Eric Dumazet
Date: Sat Jul 10 2010 - 02:17:53 EST


Le samedi 10 juillet 2010 Ã 00:18 -0300, Felipe W Damasio a Ãcrit :
> Hi Mr. Dumazet,
>
> 2010/7/9 Eric Dumazet <eric.dumazet@xxxxxxxxx>:
> > Reviewing tproxy stuff I spotted a problem in nf_tproxy_assign_sock()
> > but I could not see how it could explain your crash.
> >
> > We can read uninitialized memory and trigger a fault in
> > nf_tproxy_assign_sock(), not later in tcp_recvmsg()...
> >
> > David, Patrick, what do you think ?
>
> But do you think that the bug that squid triggered was caused by the
> TProxy code?
>

I dont think so, but I was asking David or Patrick another point of
view.

Strange thing with your crash report is CR2 value, with unexpected value
of 000000000b388000 while RAX value is dce8dce85d415d41

Faulting instruction is :

48 83 b8 b0 00 00 00 00 cmpq $0x0,0xb0(%rax)

So I would have expected CR2 being RAX+0xb0, but its not.



> Or is related to the network-stack in some other point.
>
> I don't know if this helps, but I'm using ebtables to remove the
> packets from the bridge, and iptables to redirect the traffic to
> squid.
>
> ebtables rules are:
>
> -p IPv4 -i eth0 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target DROP
> -p IPv4 -i eth1 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target DROP
>
>
> iptables -t mangle -L -n is:
>
> iptables -t mangle -L -n
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
> DIVERT tcp -- 0.0.0.0/0 0.0.0.0/0 socket
> extrachain tcp -- 0.0.0.0/0 0.0.0.0/0 tcp
> dpt:80 ctstate NEW
> TPROXY tcp -- 0.0.0.0/0 !201.40.162.5 tcp
> dpt:80 connmark match 0x0 TPROXY redirect 127.0.0.1:3127 mark 0x1/0x1
> TPROXY tcp -- 0.0.0.0/0 !201.40.162.5 tcp
> dpt:80 connmark match 0x1 TPROXY redirect 127.0.0.1:3128 mark 0x1/0x1
> TPROXY tcp -- 0.0.0.0/0 !201.40.162.5 tcp
> dpt:80 connmark match 0x2 TPROXY redirect 127.0.0.1:3129 mark 0x1/0x1
>
> Chain DIVERT (1 references)
> target prot opt source destination
> MARK all -- 0.0.0.0/0 0.0.0.0/0 MARK xset
> 0x1/0xffffffff
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
>
> Chain extrachain (1 references)
> target prot opt source destination
> CONNMARK all -- 0.0.0.0/0 0.0.0.0/0 statistic
> mode nth every 35 CONNMARK and 0x0
> CONNMARK all -- 0.0.0.0/0 0.0.0.0/0 statistic
> mode nth every 35 packet 1 CONNMARK xset 0x1/0xffffffff
> CONNMARK all -- 0.0.0.0/0 0.0.0.0/0 statistic
> mode nth every 35 packet 2 CONNMARK xset 0x2/0xffffffff
>
> Don't know if the code on these can be traced back to tcp_recvmsg()
> accessing some wrong memory address...
>
> Cheers,
>
> Felipe Damasio


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/