linux-stable.git/net/ipv6/ip6_input.c, branch v3.10.78

net: Fix memory leak if TPROXY used with TCP early demux

2014-02-06T19:08:17+00:00

[ Upstream commit a452ce345d63ddf92cd101e4196569f8718ad319 ]

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:
    [] kmem_cache_alloc+0xad/0xb9
    [] sk_prot_alloc+0x29/0xc5
    [] sk_clone_lock+0x14/0x283
    [] inet_csk_clone_lock+0xf/0x7b
    [] netlink_broadcast+0x14/0x16
    [] tcp_create_openreq_child+0x1b/0x4c3
    [] tcp_v4_syn_recv_sock+0x38/0x25d
    [] tcp_check_req+0x25c/0x3d0
    [] tcp_v4_do_rcv+0x287/0x40e
    [] ip_route_input_noref+0x843/0xa55
    [] tcp_v4_rcv+0x4c9/0x725
    [] ip_local_deliver_finish+0xe9/0x154
    [] __netif_receive_skb+0x4b2/0x514
    [] process_backlog+0xee/0x1c5
    [] net_rx_action+0xa7/0x200
    [] 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 
Signed-off-by: Holger Eitzenberger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: don't accept node local multicast traffic from the wire

2013-03-29T18:57:33+00:00

Erik Hugne's errata proposal (Errata ID: 3480) to RFC4291 has been
verified: http://www.rfc-editor.org/errata_search.php?eid=3480

We have to check for pkt_type and loopback flag because either the
packets are allowed to travel over the loopback interface (in which case
pkt_type is PACKET_HOST and IFF_LOOPBACK flag is set) or they travel
over a non-loopback interface back to us (in which case PACKET_TYPE is
PACKET_LOOPBACK and IFF_LOOPBACK flag is not set).

Cc: Erik Hugne 
Cc: YOSHIFUJI Hideaki 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

ipv6: stop multicast forwarding to process interface scoped addresses

2013-03-08T17:28:20+00:00

v2:
a) used struct ipv6_addr_props

v3:
a) reverted changes for ipv6_addr_props

v4:
a) do not use __ipv6_addr_needs_scope_id

Cc: YOSHIFUJI Hideaki 
Signed-off-by: Hannes Frederic Sowa 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

ipv[4|6]: correct dropwatch false positive in local_deliver_finish

2013-03-01T20:56:29+00:00

I had a report recently of a user trying to use dropwatch to localise some frame
loss, and they were getting false positives.  Turned out they were using a user
space SCTP stack that used raw sockets to grab frames.  When we don't have a
registered protocol for a given packet, we record it as a drop, even if a raw
socket receieves the frame.  We should only record the drop in the event a raw
socket doesnt exist to receive the frames

Tested by the reported successfully

Signed-off-by: Neil Horman 
Reported-by: William Reich 
Tested-by: William Reich 
CC: "David S. Miller" 
CC: William Reich 
CC: eric.dumazet@gmail.com
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

ipv6: don't accept multicast traffic with scope 0

2013-02-11T19:00:54+00:00

v2:
a) moved before multicast source address check
b) changed comment to netdev style

Cc: Erik Hugne 
Cc: YOSHIFUJI Hideaki 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: Hannes Frederic Sowa 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

ipv6: Store Router Alert option in IP6CB directly.

2013-01-14T01:17:14+00:00

Router Alert option is very small and we can store the value
itself in the skb.

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

ipv6: Make ipv6_is_mld() inline and use it from ip6_mc_input().

2013-01-14T01:17:14+00:00

Move generalized version of ipv6_is_mld() to header,
and use it from ip6_mc_input().

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

net: TCP early demux cleanup

2012-07-30T21:53:21+00:00

early_demux() handlers should be called in RCU context, and as we
use skb_dst_set_noref(skb, dst), caller must not exit from RCU context
before dst use (skb_dst(skb)) or release (skb_drop(dst))

Therefore, rcu_read_lock()/rcu_read_unlock() pairs around
->early_demux() are confusing and not needed :

Protocol handlers are already in an RCU read lock section.
(__netif_receive_skb() does the rcu_read_lock() )

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

ipv6: Early TCP socket demux

2012-07-26T22:50:39+00:00

This is the IPv6 missing bits for infrastructure added in commit
41063e9dd1195 (ipv4: Early TCP socket demux.)

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

inet: Sanitize inet{,6} protocol demux.

2012-06-20T01:56:21+00:00

Don't pretend that inet_protos[] and inet6_protos[] are hashes, thay
are just a straight arrays.  Remove all unnecessary hash masking.

Document MAX_INET_PROTOS.

Use RAW_HTABLE_SIZE when appropriate.

Reported-by: Ben Hutchings 
Signed-off-by: David S. Miller