linux-stable.git/net/ipv6/ip6_input.c, branch linux-3.16.y

ipv6: drop incoming packets having a v4mapped source address

2019-12-19T15:57:57+00:00

commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 upstream.

This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.

After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls reqsk_queue_hash_req()

reqsk_queue_hash_req() calls sk_ehashfn(sk)

At this point we have AF_INET6 sockets, and the heuristic
used by sk_ehashfn() to either hash the IPv4 or IPv6 addresses
is to use ipv6_addr_v4mapped(&sk->sk_v6_daddr)

For the particular spoofed packet, we end up hashing V4 addresses
which were not initialized by the TCP IPv6 stack, so KMSAN fired
a warning.

I first fixed sk_ehashfn() to test both source and destination addresses,
but then faced various problems, including user-space programs
like packetdrill that had similar assumptions.

Instead of trying to fix the whole ecosystem, it is better
to admit that we have a dual stack behavior, and that we
can not build linux kernels without V4 stack anyway.

The dual stack API automatically forces the traffic to be IPv4
if v4mapped addresses are used at bind() or connect(), so it makes
no sense to allow IPv6 traffic to use the same v4mapped class.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet 
Cc: Florian Westphal 
Cc: Hannes Frederic Sowa 
Reported-by: syzbot 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

ipv6: Make MLD packets to only be processed locally

2015-08-10T16:10:15+00:00

commit 4c938d22c88a9ddccc8c55a85e0430e9c62b1ac5 upstream.

Before commit daad151263cf ("ipv6: Make ipv6_is_mld() inline and use it
from ip6_mc_input().") MLD packets were only processed locally. After the
change, a copy of MLD packet goes through ip6_mr_input, causing
MRT6MSG_NOCACHE message to be generated to user space.

Make MLD packet only processed locally.

Fixes: daad151263cf ("ipv6: Make ipv6_is_mld() inline and use it from ip6_mc_input().")
Signed-off-by: Hermin Anggawijaya 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques

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

2014-01-28T00:22:11+00:00

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

net: add SNMP counters tracking incoming ECN bits

2013-08-09T05:24:59+00:00

With GRO/LRO processing, there is a problem because Ip[6]InReceives SNMP
counters do not count the number of frames, but number of aggregated
segments.

Its probably too late to change this now.

This patch adds four new counters, tracking number of frames, regardless
of LRO/GRO, and on a per ECN status basis, for IPv4 and IPv6.

Ip[6]NoECTPkts : Number of packets received with NOECT
Ip[6]ECT1Pkts  : Number of packets received with ECT(1)
Ip[6]ECT0Pkts  : Number of packets received with ECT(0)
Ip[6]CEPkts    : Number of packets received with Congestion Experienced

lph37:~# nstat | egrep "Pkts|InReceive"
IpInReceives                    1634137            0.0
Ip6InReceives                   3714107            0.0
Ip6InNoECTPkts                  19205              0.0
Ip6InECT0Pkts                   52651828           0.0
IpExtInNoECTPkts                33630              0.0
IpExtInECT0Pkts                 15581379           0.0
IpExtInCEPkts                   6                  0.0

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

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