1. 05 Jul, 2016 2 commits
  2. 04 Jul, 2016 1 commit
  3. 01 Jul, 2016 3 commits
    • Richard Alpe's avatar
      tipc: fix nl compat regression for link statistics · 55e77a3e
      Richard Alpe authored
      Fix incorrect use of nla_strlcpy() where the first NLA_HDRLEN bytes
      of the link name where left out.
      
      Making the output of tipc-config -ls look something like:
      Link statistics:
      dcast-link
      1:data0-1.1.2:data0
      1:data0-1.1.3:data0
      
      Also, for the record, the patch that introduce this regression
      claims "Sending the whole object out can cause a leak". Which isn't
      very likely as this is a compat layer, where the data we are parsing
      is generated by us and we know the string to be NULL terminated. But
      you can of course never be to secure.
      
      Fixes: 5d2be142 (tipc: fix an infoleak in tipc_nl_compat_link_dump)
      Signed-off-by: default avatarRichard Alpe <richard.alpe@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55e77a3e
    • WANG Cong's avatar
      net_sched: fix mirrored packets checksum · 82a31b92
      WANG Cong authored
      Similar to commit 9b368814 ("net: fix bridge multicast packet checksum validation")
      we need to fixup the checksum for CHECKSUM_COMPLETE when
      pushing skb on RX path. Otherwise we get similar splats.
      
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82a31b92
    • David S. Miller's avatar
      packet: Use symmetric hash for PACKET_FANOUT_HASH. · eb70db87
      David S. Miller authored
      People who use PACKET_FANOUT_HASH want a symmetric hash, meaning that
      they want packets going in both directions on a flow to hash to the
      same bucket.
      
      The core kernel SKB hash became non-symmetric when the ipv6 flow label
      and other entities were incorporated into the standard flow hash order
      to increase entropy.
      
      But there are no users of PACKET_FANOUT_HASH who want an assymetric
      hash, they all want a symmetric one.
      
      Therefore, use the flow dissector to compute a flat symmetric hash
      over only the protocol, addresses and ports.  This hash does not get
      installed into and override the normal skb hash, so this change has
      no effect whatsoever on the rest of the stack.
      Reported-by: default avatarEric Leblond <eric@regit.org>
      Tested-by: default avatarEric Leblond <eric@regit.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb70db87
  4. 30 Jun, 2016 1 commit
  5. 29 Jun, 2016 10 commits
  6. 28 Jun, 2016 3 commits
    • daniel's avatar
      Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address · 0888d5f3
      daniel authored
      The bridge is falsly dropping ipv6 mulitcast packets if there is:
       1. No ipv6 address assigned on the brigde.
       2. No external mld querier present.
       3. The internal querier enabled.
      
      When the bridge fails to build mld queries, because it has no
      ipv6 address, it slilently returns, but keeps the local querier enabled.
      This specific case causes confusing packet loss.
      
      Ipv6 multicast snooping can only work if:
       a) An external querier is present
       OR
       b) The bridge has an ipv6 address an is capable of sending own queries
      
      Otherwise it has to forward/flood the ipv6 multicast traffic,
      because snooping cannot work.
      
      This patch fixes the issue by adding a flag to the bridge struct that
      indicates that there is currently no ipv6 address assinged to the bridge
      and returns a false state for the local querier in
      __br_multicast_querier_exists().
      
      Special thanks to Linus Lüssing.
      
      Fixes: d1d81d4c ("bridge: check return value of ipv6_dev_get_saddr()")
      Signed-off-by: default avatarDaniel Danzberger <daniel@dd-wrt.com>
      Acked-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0888d5f3
    • Jouni Malinen's avatar
      mac80211: Fix mesh estab_plinks counting in STA removal case · 126e7557
      Jouni Malinen authored
      If a user space program (e.g., wpa_supplicant) deletes a STA entry that
      is currently in NL80211_PLINK_ESTAB state, the number of established
      plinks counter was not decremented and this could result in rejecting
      new plink establishment before really hitting the real maximum plink
      limit. For !user_mpm case, this decrementation is handled by
      mesh_plink_deactive().
      
      Fix this by decrementing estab_plinks on STA deletion
      (mesh_sta_cleanup() gets called from there) so that the counter has a
      correct value and the Beacon frame advertisement in Mesh Configuration
      element shows the proper value for capability to accept additional
      peers.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      126e7557
    • Tom Goff's avatar
      ipmr/ip6mr: Initialize the last assert time of mfc entries. · 70a0dec4
      Tom Goff authored
      This fixes wrong-interface signaling on 32-bit platforms for entries
      created when jiffies > 2^31 + MFC_ASSERT_THRESH.
      Signed-off-by: default avatarTom Goff <thomas.goff@ll.mit.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70a0dec4
  7. 27 Jun, 2016 2 commits
  8. 23 Jun, 2016 4 commits
  9. 22 Jun, 2016 2 commits
    • Jon Paul Maloy's avatar
      tipc: unclone unbundled buffers before forwarding · 27777daa
      Jon Paul Maloy authored
      When extracting an individual message from a received "bundle" buffer,
      we just create a clone of the base buffer, and adjust it to point into
      the right position of the linearized data area of the latter. This works
      well for regular message reception, but during periods of extremely high
      load it may happen that an extracted buffer, e.g, a connection probe, is
      reversed and forwarded through an external interface while the preceding
      extracted message is still unhandled. When this happens, the header or
      data area of the preceding message will be partially overwritten by a
      MAC header, leading to unpredicatable consequences, such as a link
      reset.
      
      We now fix this by ensuring that the msg_reverse() function never
      returns a cloned buffer, and that the returned buffer always contains
      sufficient valid head and tail room to be forwarded.
      Reported-by: default avatarErik Hugne <erik.hugne@gmail.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27777daa
    • Jiri Slaby's avatar
      kcm: fix /proc memory leak · d19af0a7
      Jiri Slaby authored
      Every open of /proc/net/kcm leaks 16 bytes of memory as is reported by
      kmemleak:
      unreferenced object 0xffff88059c0e3458 (size 192):
        comm "cat", pid 1401, jiffies 4294935742 (age 310.720s)
        hex dump (first 32 bytes):
          28 45 71 96 05 88 ff ff 00 10 00 00 00 00 00 00  (Eq.............
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff8156a2de>] kmem_cache_alloc_trace+0x16e/0x230
          [<ffffffff8162a479>] seq_open+0x79/0x1d0
          [<ffffffffa0578510>] kcm_seq_open+0x0/0x30 [kcm]
          [<ffffffff8162a479>] seq_open+0x79/0x1d0
          [<ffffffff8162a8cf>] __seq_open_private+0x2f/0xa0
          [<ffffffff81712548>] seq_open_net+0x38/0xa0
      ...
      
      It is caused by a missing free in the ->release path. So fix it by
      providing seq_release_net as the ->release method.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Fixes: cd6e111b (kcm: Add statistics and proc interfaces)
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Tom Herbert <tom@herbertland.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d19af0a7
  10. 18 Jun, 2016 2 commits
  11. 17 Jun, 2016 2 commits
    • Sowmini Varadhan's avatar
      RDS: TCP: rds_tcp_accept_one() should transition socket from RESETTING to UP · 3bb549ae
      Sowmini Varadhan authored
      The state of the rds_connection after rds_tcp_reset_callbacks() would
      be RDS_CONN_RESETTING and this is the value that should be passed
      by rds_tcp_accept_one()  to rds_connect_path_complete() to transition
      the socket to RDS_CONN_UP.
      
      Fixes: b5c21c0947c1 ("RDS: TCP: fix race windows in send-path quiescence
      by rds_tcp_accept_one()")
      Signed-off-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bb549ae
    • Jon Paul Maloy's avatar
      tipc: fix socket timer deadlock · f1d048f2
      Jon Paul Maloy authored
      We sometimes observe a 'deadly embrace' type deadlock occurring
      between mutually connected sockets on the same node. This happens
      when the one-hour peer supervision timers happen to expire
      simultaneously in both sockets.
      
      The scenario is as follows:
      
      CPU 1:                          CPU 2:
      --------                        --------
      tipc_sk_timeout(sk1)            tipc_sk_timeout(sk2)
        lock(sk1.slock)                 lock(sk2.slock)
        msg_create(probe)               msg_create(probe)
        unlock(sk1.slock)               unlock(sk2.slock)
        tipc_node_xmit_skb()            tipc_node_xmit_skb()
          tipc_node_xmit()                tipc_node_xmit()
            tipc_sk_rcv(sk2)                tipc_sk_rcv(sk1)
              lock(sk2.slock)                 lock((sk1.slock)
              filter_rcv()                    filter_rcv()
                tipc_sk_proto_rcv()             tipc_sk_proto_rcv()
                  msg_create(probe_rsp)           msg_create(probe_rsp)
                  tipc_sk_respond()               tipc_sk_respond()
                    tipc_node_xmit_skb()            tipc_node_xmit_skb()
                      tipc_node_xmit()                tipc_node_xmit()
                        tipc_sk_rcv(sk1)                tipc_sk_rcv(sk2)
                          lock((sk1.slock)                lock((sk2.slock)
                          ===> DEADLOCK                   ===> DEADLOCK
      
      Further analysis reveals that there are three different locations in the
      socket code where tipc_sk_respond() is called within the context of the
      socket lock, with ensuing risk of similar deadlocks.
      
      We now solve this by passing a buffer queue along with all upcalls where
      sk_lock.slock may potentially be held. Response or rejected message
      buffers are accumulated into this queue instead of being sent out
      directly, and only sent once we know we are safely outside the slock
      context.
      Reported-by: default avatarGUNA <gbalasun@gmail.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1d048f2
  12. 16 Jun, 2016 2 commits
    • Simon Horman's avatar
      sit: correct IP protocol used in ipip6_err · d5d8760b
      Simon Horman authored
      Since 32b8a8e5 ("sit: add IPv4 over IPv4 support")
      ipip6_err() may be called for packets whose IP protocol is
      IPPROTO_IPIP as well as those whose IP protocol is IPPROTO_IPV6.
      
      In the case of IPPROTO_IPIP packets the correct protocol value is not
      passed to ipv4_update_pmtu() or ipv4_redirect().
      
      This patch resolves this problem by using the IP protocol of the packet
      rather than a hard-coded value. This appears to be consistent
      with the usage of the protocol of a packet by icmp_socket_deliver()
      the caller of ipip6_err().
      
      I was able to exercise the redirect case by using a setup where an ICMP
      redirect was received for the destination of the encapsulated packet.
      However, it appears that although incorrect the protocol field is not used
      in this case and thus no problem manifests.  On inspection it does not
      appear that a problem will manifest in the fragmentation needed/update pmtu
      case either.
      
      In short I believe this is a cosmetic fix. None the less, the use of
      IPPROTO_IPV6 seems wrong and confusing.
      Reviewed-by: default avatarDinan Gunawardena <dinan.gunawardena@netronome.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d5d8760b
    • Alexei Starovoitov's avatar
      bpf: fix matching of data/data_end in verifier · 19de99f7
      Alexei Starovoitov authored
      The ctx structure passed into bpf programs is different depending on bpf
      program type. The verifier incorrectly marked ctx->data and ctx->data_end
      access based on ctx offset only. That caused loads in tracing programs
      int bpf_prog(struct pt_regs *ctx) { .. ctx->ax .. }
      to be incorrectly marked as PTR_TO_PACKET which later caused verifier
      to reject the program that was actually valid in tracing context.
      Fix this by doing program type specific matching of ctx offsets.
      
      Fixes: 969bf05e ("bpf: direct packet access")
      Reported-by: default avatarSasha Goldshtein <goldshtn@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19de99f7
  13. 15 Jun, 2016 6 commits
    • Eric Dumazet's avatar
      gre: fix error handler · e582615a
      Eric Dumazet authored
      1) gre_parse_header() can be called from gre_err()
      
         At this point transport header points to ICMP header, not the inner
      header.
      
      2) We can not really change transport header as ipgre_err() will later
      assume transport header still points to ICMP header (using icmp_hdr())
      
      3) pskb_may_pull() logic in gre_parse_header() really works
        if we are interested at zone pointed by skb->data
      
      4) As Jiri explained in commit b7f8fe25 ("gre: do not pull header in
      ICMP error processing") we should not pull headers in error handler.
      
      So this fix :
      
      A) changes gre_parse_header() to use skb->data instead of
      skb_transport_header()
      
      B) Adds a nhs parameter to gre_parse_header() so that we can skip the
      not pulled IP header from error path.
        This offset is 0 for normal receive path.
      
      C) remove obsolete IPV6 includes
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Jiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e582615a
    • Ying Xue's avatar
      tipc: eliminate uninitialized variable warning · c91522f8
      Ying Xue authored
      net/tipc/link.c: In function ‘tipc_link_timeout’:
      net/tipc/link.c:744:28: warning: ‘mtyp’ may be used uninitialized in this function [-Wuninitialized]
      
      Fixes: 42b18f60 ("tipc: refactor function tipc_link_timeout()")
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c91522f8
    • Ying Xue's avatar
      tipc: fix suspicious RCU usage · 66d95b67
      Ying Xue authored
      When run tipcTS&tipcTC test suite, the following complaint appears:
      
      [   56.926168] ===============================
      [   56.926169] [ INFO: suspicious RCU usage. ]
      [   56.926171] 4.7.0-rc1+ #160 Not tainted
      [   56.926173] -------------------------------
      [   56.926174] net/tipc/bearer.c:408 suspicious rcu_dereference_protected() usage!
      [   56.926175]
      [   56.926175] other info that might help us debug this:
      [   56.926175]
      [   56.926177]
      [   56.926177] rcu_scheduler_active = 1, debug_locks = 1
      [   56.926179] 3 locks held by swapper/4/0:
      [   56.926180]  #0:  (((&req->timer))){+.-...}, at: [<ffffffff810e79b5>] call_timer_fn+0x5/0x340
      [   56.926203]  #1:  (&(&req->lock)->rlock){+.-...}, at: [<ffffffffa000c29b>] disc_timeout+0x1b/0xd0 [tipc]
      [   56.926212]  #2:  (rcu_read_lock){......}, at: [<ffffffffa00055e0>] tipc_bearer_xmit_skb+0xb0/0x2e0 [tipc]
      [   56.926218]
      [   56.926218] stack backtrace:
      [   56.926221] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.7.0-rc1+ #160
      [   56.926222] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [   56.926224]  0000000000000000 ffff880016803d28 ffffffff813c4423 ffff8800154252c0
      [   56.926227]  0000000000000001 ffff880016803d58 ffffffff810b7512 ffff8800124d8120
      [   56.926230]  ffff880013f8a160 ffff8800132b5ccc ffff8800124d8120 ffff880016803d88
      [   56.926234] Call Trace:
      [   56.926235]  <IRQ>  [<ffffffff813c4423>] dump_stack+0x67/0x94
      [   56.926250]  [<ffffffff810b7512>] lockdep_rcu_suspicious+0xe2/0x120
      [   56.926256]  [<ffffffffa00051f1>] tipc_l2_send_msg+0x131/0x1c0 [tipc]
      [   56.926261]  [<ffffffffa000567c>] tipc_bearer_xmit_skb+0x14c/0x2e0 [tipc]
      [   56.926266]  [<ffffffffa00055e0>] ? tipc_bearer_xmit_skb+0xb0/0x2e0 [tipc]
      [   56.926273]  [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc]
      [   56.926278]  [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc]
      [   56.926283]  [<ffffffffa000c2d6>] disc_timeout+0x56/0xd0 [tipc]
      [   56.926288]  [<ffffffff810e7a68>] call_timer_fn+0xb8/0x340
      [   56.926291]  [<ffffffff810e79b5>] ? call_timer_fn+0x5/0x340
      [   56.926296]  [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc]
      [   56.926300]  [<ffffffff810e8f4a>] run_timer_softirq+0x23a/0x390
      [   56.926306]  [<ffffffff810f89ff>] ? clockevents_program_event+0x7f/0x130
      [   56.926316]  [<ffffffff819727c3>] __do_softirq+0xc3/0x4a2
      [   56.926323]  [<ffffffff8106ba5a>] irq_exit+0x8a/0xb0
      [   56.926327]  [<ffffffff81972456>] smp_apic_timer_interrupt+0x46/0x60
      [   56.926331]  [<ffffffff81970a49>] apic_timer_interrupt+0x89/0x90
      [   56.926333]  <EOI>  [<ffffffff81027fda>] ? default_idle+0x2a/0x1a0
      [   56.926340]  [<ffffffff81027fd8>] ? default_idle+0x28/0x1a0
      [   56.926342]  [<ffffffff810289cf>] arch_cpu_idle+0xf/0x20
      [   56.926345]  [<ffffffff810adf0f>] default_idle_call+0x2f/0x50
      [   56.926347]  [<ffffffff810ae145>] cpu_startup_entry+0x215/0x3e0
      [   56.926353]  [<ffffffff81040ad9>] start_secondary+0xf9/0x100
      
      The warning appears as rtnl_dereference() is wrongly used in
      tipc_l2_send_msg() under RCU read lock protection. Instead the proper
      usage should be that rcu_dereference_rtnl() is called here.
      
      Fixes: 5b7066c3 ("tipc: stricter filtering of packets in bearer layer")
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66d95b67
    • Florian Westphal's avatar
      htb: call qdisc_root with rcu read lock held · 0ee13627
      Florian Westphal authored
      saw a debug splat:
      net/include/net/sch_generic.h:287 suspicious rcu_dereference_check() usage!
      other info that might help us debug this:
      rcu_scheduler_active = 1, debug_locks = 0
       2 locks held by kworker/2:1/710:
        #0:  ("events"){.+.+.+}, at: [<ffffffff8106ca1d>]
        #1:  ((&q->work)){+.+...}, at: [<ffffffff8106ca1d>] process_one_work+0x14d/0x690
      Workqueue: events htb_work_func
      Call Trace:
       [<ffffffff812dc763>] dump_stack+0x85/0xc2
       [<ffffffff8109fee7>] lockdep_rcu_suspicious+0xe7/0x120
       [<ffffffff814ced47>] htb_work_func+0x67/0x70
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ee13627
    • Jamal Hadi Salim's avatar
      net sched actions: bug fix dumping actions directly didnt produce NLMSG_DONE · ebecaa66
      Jamal Hadi Salim authored
      This refers to commands to direct action access as follows:
      
      sudo tc actions add action drop index 12
      sudo tc actions add action pipe index 10
      
      And then dumping them like so:
      sudo tc actions ls action gact
      
      iproute2 worked because it depended on absence of TCA_ACT_TAB TLV
      as end of message.
      This fix has been tested with iproute2 and is backward compatible.
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebecaa66
    • WANG Cong's avatar
      act_ipt: fix a bind refcnt leak · d15eccea
      WANG Cong authored
      And avoid calling tcf_hash_check() twice.
      
      Fixes: a57f19d3 ("net sched: ipt action fix late binding")
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d15eccea