tproxy: nf_tproxy_assign_sock() can handle tw sockets
in [Kernel]
|
Prev: QoS and/or fair queueing: Stateless NAT BUG
Next: Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: David Miller on 9 Jul 2010 14:00 From: Eric Dumazet <eric.dumazet(a)gmail.com> Date: Fri, 09 Jul 2010 19:13:00 +0200 > 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 ? > > Thanks > > [PATCH] tproxy: nf_tproxy_assign_sock() can handle tw sockets > > transparent field of a socket is either inet_twsk(sk)->tw_transparent > for timewait sockets, or inet_sk(sk)->transparent for other sockets > (TCP/UDP). > > Signed-off-by: Eric Dumazet <eric.dumazet(a)gmail.com> Looks fine to me: Acked-by: David S. Miller <davem(a)davemloft.net> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe W Damasio on 9 Jul 2010 14:20 Hi, 2010/7/9 Eric Dumazet <eric.dumazet(a)gmail.com>: > 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()... Well, since I can't reproduce the bug, if you think this patch solves my problem, I'll tell my bosses that we can put back the production machine online. But anyway, if there's test you think I can run, I have same the same hardware on a lab using the same setup as the production environment... Thanks, Felipe Damasio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe W Damasio on 9 Jul 2010 23:20 Hi Mr. Dumazet, 2010/7/9 Eric Dumazet <eric.dumazet(a)gmail.com>: > 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? 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric Dumazet on 10 Jul 2010 02:20 Le samedi 10 juillet 2010 à 00:18 -0300, Felipe W Damasio a écrit : > Hi Mr. Dumazet, > > 2010/7/9 Eric Dumazet <eric.dumazet(a)gmail.com>: > > 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 10 Jul 2010 15:40
From: Eric Dumazet <eric.dumazet(a)gmail.com> Date: Sat, 10 Jul 2010 08:17:29 +0200 > 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. It could be corruption from elsewhere. Those last four hex digits (0x5d415d41) are "]A]A" in ascii, but that could just be coincidence. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |