mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-15 21:30:43 +00:00
a452ce345d
I see a memory leak when using a transparent HTTP proxy using TPROXY
together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable):
unreferenced object 0xffff88008cba4a40 (size 1696):
comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s)
hex dump (first 32 bytes):
0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00 .. j@..7..2.....
02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff810b710a>] kmem_cache_alloc+0xad/0xb9
[<ffffffff81270185>] sk_prot_alloc+0x29/0xc5
[<ffffffff812702cf>] sk_clone_lock+0x14/0x283
[<ffffffff812aaf3a>] inet_csk_clone_lock+0xf/0x7b
[<ffffffff8129a893>] netlink_broadcast+0x14/0x16
[<ffffffff812c1573>] tcp_create_openreq_child+0x1b/0x4c3
[<ffffffff812c033e>] tcp_v4_syn_recv_sock+0x38/0x25d
[<ffffffff812c13e4>] tcp_check_req+0x25c/0x3d0
[<ffffffff812bf87a>] tcp_v4_do_rcv+0x287/0x40e
[<ffffffff812a08a7>] ip_route_input_noref+0x843/0xa55
[<ffffffff812bfeca>] tcp_v4_rcv+0x4c9/0x725
[<ffffffff812a26f4>] ip_local_deliver_finish+0xe9/0x154
[<ffffffff8127a927>] __netif_receive_skb+0x4b2/0x514
[<ffffffff8127aa77>] process_backlog+0xee/0x1c5
[<ffffffff8127c949>] net_rx_action+0xa7/0x200
[<ffffffff81209d86>] add_interrupt_randomness+0x39/0x157
But there are many more, resulting in the machine going OOM after some
days.
From looking at the TPROXY code, and with help from Florian, I see
that the memory leak is introduced in tcp_v4_early_demux():
void tcp_v4_early_demux(struct sk_buff *skb)
{
/* ... */
iph = ip_hdr(skb);
th = tcp_hdr(skb);
if (th->doff < sizeof(struct tcphdr) / 4)
return;
sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo,
iph->saddr, th->source,
iph->daddr, ntohs(th->dest),
skb->skb_iif);
if (sk) {
skb->sk = sk;
where the socket is assigned unconditionally to skb->sk, also bumping
the refcnt on it. This is problematic, because in our case the skb
has already a socket assigned in the TPROXY target. This then results
in the leak I see.
The very same issue seems to be with IPv6, but haven't tested.
Reviewed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
||
|---|---|---|
| .. | ||
| netfilter | ||
| af_inet.c | ||
| ah4.c | ||
| arp.c | ||
| cipso_ipv4.c | ||
| datagram.c | ||
| devinet.c | ||
| esp4.c | ||
| fib_frontend.c | ||
| fib_lookup.h | ||
| fib_rules.c | ||
| fib_semantics.c | ||
| fib_trie.c | ||
| gre_demux.c | ||
| gre_offload.c | ||
| icmp.c | ||
| igmp.c | ||
| inet_connection_sock.c | ||
| inet_diag.c | ||
| inet_fragment.c | ||
| inet_hashtables.c | ||
| inet_lro.c | ||
| inet_timewait_sock.c | ||
| inetpeer.c | ||
| ip_forward.c | ||
| ip_fragment.c | ||
| ip_gre.c | ||
| ip_input.c | ||
| ip_options.c | ||
| ip_output.c | ||
| ip_sockglue.c | ||
| ip_tunnel_core.c | ||
| ip_tunnel.c | ||
| ip_vti.c | ||
| ipcomp.c | ||
| ipconfig.c | ||
| ipip.c | ||
| ipmr.c | ||
| Kconfig | ||
| Makefile | ||
| netfilter.c | ||
| ping.c | ||
| proc.c | ||
| protocol.c | ||
| raw.c | ||
| route.c | ||
| syncookies.c | ||
| sysctl_net_ipv4.c | ||
| tcp_bic.c | ||
| tcp_cong.c | ||
| tcp_cubic.c | ||
| tcp_diag.c | ||
| tcp_fastopen.c | ||
| tcp_highspeed.c | ||
| tcp_htcp.c | ||
| tcp_hybla.c | ||
| tcp_illinois.c | ||
| tcp_input.c | ||
| tcp_ipv4.c | ||
| tcp_lp.c | ||
| tcp_memcontrol.c | ||
| tcp_metrics.c | ||
| tcp_minisocks.c | ||
| tcp_offload.c | ||
| tcp_output.c | ||
| tcp_probe.c | ||
| tcp_scalable.c | ||
| tcp_timer.c | ||
| tcp_vegas.c | ||
| tcp_vegas.h | ||
| tcp_veno.c | ||
| tcp_westwood.c | ||
| tcp_yeah.c | ||
| tcp.c | ||
| tunnel4.c | ||
| udp_diag.c | ||
| udp_impl.h | ||
| udp_offload.c | ||
| udp.c | ||
| udplite.c | ||
| xfrm4_input.c | ||
| xfrm4_mode_beet.c | ||
| xfrm4_mode_transport.c | ||
| xfrm4_mode_tunnel.c | ||
| xfrm4_output.c | ||
| xfrm4_policy.c | ||
| xfrm4_state.c | ||
| xfrm4_tunnel.c | ||