Skip to content
  1. Sep 09, 2017
    • Daniel Borkmann's avatar
      bpf: don't select potentially stale ri->map from buggy xdp progs · 109980b8
      Daniel Borkmann authored
      We can potentially run into a couple of issues with the XDP
      bpf_redirect_map() helper. The ri->map in the per CPU storage
      can become stale in several ways, mostly due to misuse, where
      we can then trigger a use after free on the map:
      
      i) prog A is calling bpf_redirect_map(), returning XDP_REDIRECT
      and running on a driver not supporting XDP_REDIRECT yet. The
      ri->map on that CPU becomes stale when the XDP program is unloaded
      on the driver, and a prog B loaded on a different driver which
      supports XDP_REDIRECT return code. prog B would have to omit
      calling to bpf_redirect_map() and just return XDP_REDIRECT, which
      would then access the freed map in xdp_do_redirect() since not
      cleared for that CPU.
      
      ii) prog A is calling bpf_redirect_map(), returning a code other
      than XDP_REDIRECT. prog A is then detached, which triggers release
      of the map. prog B is attached which, similarly as in i), would
      just return XDP_REDIRECT without having called bpf_redirect_map()
      and thus be accessing the freed map in xdp_do_redirect() since
      not cleared for that CPU.
      
      iii) prog A is attached to generic XDP, calling the bpf_redirect_map()
      helper and returning XDP_REDIRECT. xdp_do_generic_redirect() is
      currently not handling ri->map (will be fixed by Jesper), so it's
      not being reset. Later loading a e.g. native prog B which would,
      say, call bpf_xdp_redirect() and then returns XDP_REDIRECT would
      find in xdp_do_redirect() that a map was set and uses that causing
      use after free on map access.
      
      Fix thus needs to avoid accessing stale ri->map pointers, naive
      way would be to call a BPF function from drivers that just resets
      it to NULL for all XDP return codes but XDP_REDIRECT and including
      XDP_REDIRECT for drivers not supporting it yet (and let ri->map
      being handled in xdp_do_generic_redirect()). There is a less
      intrusive way w/o letting drivers call a reset for each BPF run.
      
      The verifier knows we're calling into bpf_xdp_redirect_map()
      helper, so it can do a small insn rewrite transparent to the prog
      itself in the sense that it fills R4 with a pointer to the own
      bpf_prog. We have that pointer at verification time anyway and
      R4 is allowed to be used as per calling convention we scratch
      R0 to R5 anyway, so they become inaccessible and program cannot
      read them prior to a write. Then, the helper would store the prog
      pointer in the current CPUs struct redirect_info. Later in
      xdp_do_*_redirect() we check whether the redirect_info's prog
      pointer is the same as passed xdp_prog pointer, and if that's
      the case then all good, since the prog holds a ref on the map
      anyway, so it is always valid at that point in time and must
      have a reference count of at least 1. If in the unlikely case
      they are not equal, it means we got a stale pointer, so we clear
      and bail out right there. Also do reset map and the owning prog
      in bpf_xdp_redirect(), so that bpf_xdp_redirect_map() and
      bpf_xdp_redirect() won't get mixed up, only the last call should
      take precedence. A tc bpf_redirect() doesn't use map anywhere
      yet, so no need to clear it there since never accessed in that
      layer.
      
      Note that in case the prog is released, and thus the map as
      well we're still under RCU read critical section at that time
      and have preemption disabled as well. Once we commit with the
      __dev_map_insert_ctx() from xdp_do_redirect_map() and set the
      map to ri->map_to_flush, we still wait for a xdp_do_flush_map()
      to finish in devmap dismantle time once flush_needed bit is set,
      so that is fine.
      
      Fixes: 97f91a7c
      
       ("bpf: add bpf_redirect_map helper routine")
      Reported-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      109980b8
    • Kees Cook's avatar
      net: tulip: Constify tulip_tbl · 9a486c9d
      Kees Cook authored
      
      
      It looks like all users of tulip_tbl are reads, so mark this table
      as read-only.
      
      $ git grep tulip_tbl  # edited to avoid line-wraps...
      interrupt.c: iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ...
      interrupt.c: iowrite32(tulip_tbl[tp->chip_id].valid_intrs&~RxPollInt, ...
      interrupt.c: iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ...
      interrupt.c: iowrite32(tulip_tbl[tp->chip_id].valid_intrs | TimerInt,
      pnic.c:      iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7);
      tulip.h:     extern struct tulip_chip_table tulip_tbl[];
      tulip_core.c:struct tulip_chip_table tulip_tbl[] = {
      tulip_core.c:iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR5);
      tulip_core.c:iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7);
      tulip_core.c:setup_timer(&tp->timer, tulip_tbl[tp->chip_id].media_timer,
      tulip_core.c:const char *chip_name = tulip_tbl[chip_idx].chip_name;
      tulip_core.c:if (pci_resource_len (pdev, 0) < tulip_tbl[chip_idx].io_size)
      tulip_core.c:ioaddr =  pci_iomap(..., tulip_tbl[chip_idx].io_size);
      tulip_core.c:tp->flags = tulip_tbl[chip_idx].flags;
      tulip_core.c:setup_timer(&tp->timer, tulip_tbl[tp->chip_id].media_timer,
      tulip_core.c:INIT_WORK(&tp->media_work, tulip_tbl[tp->chip_id].media_task);
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jarod Wilson <jarod@redhat.com>
      Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-parisc@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a486c9d
    • Ivan Khoronzhuk's avatar
      net: ethernet: ti: netcp_core: no need in netif_napi_del · e333ac1f
      Ivan Khoronzhuk authored
      
      
      Don't remove rx_napi specifically just before free_netdev(),
      it's supposed to be done in it and is confusing w/o tx_napi deletion.
      
      Signed-off-by: default avatarIvan Khoronzhuk <ivan.khoronzhuk@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e333ac1f
    • Mathieu Malaterre's avatar
      davicom: Display proper debug level up to 6 · 0fdbedc7
      Mathieu Malaterre authored
      
      
      This will make it explicit some messages are of the form:
      dm9000_dbg(db, 5, ...
      
      Signed-off-by: default avatarMathieu Malaterre <malat@debian.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fdbedc7
    • Baruch Siach's avatar
      net: phy: sfp: rename dt properties to match the binding · 25ee0793
      Baruch Siach authored
      
      
      Make the Rx rate select control gpio property name match the documented
      binding. This would make the addition of 'rate-select1-gpios' for SFP+
      support more natural.
      
      Also, make the MOD-DEF0 gpio property name match the documentation.
      
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25ee0793
    • Baruch Siach's avatar
      dt-binding: net: sfp binding documentation · 3ef37140
      Baruch Siach authored
      
      
      Add device-tree binding documentation SFP transceivers. Support for SFP
      transceivers has been recently introduced (drivers/net/phy/sfp.c).
      
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ef37140
    • Baruch Siach's avatar
      165da358
    • Baruch Siach's avatar
      dt-bindings: net: don't confuse with generic PHY property · c43593d8
      Baruch Siach authored
      This complements commit 9a94b3a4
      
       (dt-binding: phy: don't confuse with
      Ethernet phy properties).
      
      The generic PHY 'phys' property sometime appears in the same node with
      the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in
      ethernet.txt to reduce confusion.
      
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c43593d8
    • Haishuang Yan's avatar
      ip6_tunnel: fix setting hop_limit value for ipv6 tunnel · 18e1173d
      Haishuang Yan authored
      
      
      Similar to vxlan/geneve tunnel, if hop_limit is zero, it should fall
      back to ip6_dst_hoplimt().
      
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18e1173d
    • Haishuang Yan's avatar
      ip_tunnel: fix setting ttl and tos value in collect_md mode · 0f693f19
      Haishuang Yan authored
      ttl and tos variables are declared and assigned, but are not used in
      iptunnel_xmit() function.
      
      Fixes: cfc7381b
      
       ("ip_tunnel: add collect_md mode to IPIP tunnel")
      Cc: Alexei Starovoitov <ast@fb.com>
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f693f19
    • Eric Dumazet's avatar
      ipv6: fix typo in fib6_net_exit() · 32a805ba
      Eric Dumazet authored
      IPv6 FIB should use FIB6_TABLE_HASHSZ, not FIB_TABLE_HASHSZ.
      
      Fixes: ba1cc08d
      
       ("ipv6: fix memory leak with multiple tables during netns destruction")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32a805ba
    • Eric Dumazet's avatar
      tcp: fix a request socket leak · 1f3b359f
      Eric Dumazet authored
      While the cited commit fixed a possible deadlock, it added a leak
      of the request socket, since reqsk_put() must be called if the BPF
      filter decided the ACK packet must be dropped.
      
      Fixes: d624d276
      
       ("tcp: fix possible deadlock in TCP stack vs BPF filter")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f3b359f
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 10807461
      David S. Miller authored
      
      
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS fixes for net
      
      The following patchset contains Netfilter/IPVS fixes for your net tree,
      they are:
      
      1) Fix SCTP connection setup when IPVS module is loaded and any scheduler
         is registered, from Xin Long.
      
      2) Don't create a SCTP connection from SCTP ABORT packets, also from
         Xin Long.
      
      3) WARN_ON() and drop packet, instead of BUG_ON() races when calling
         nf_nat_setup_info(). This is specifically a longstanding problem
         when br_netfilter with conntrack support is in place, patch from
         Florian Westphal.
      
      4) Avoid softlock splats via iptables-restore, also from Florian.
      
      5) Revert NAT hashtable conversion to rhashtable, semantics of rhlist
         are different from our simple NAT hashtable, this has been causing
         problems in the recent Linux kernel releases. From Florian.
      
      6) Add per-bucket spinlock for NAT hashtable, so at least we restore
         one of the benefits we got from the previous rhashtable conversion.
      
      7) Fix incorrect hashtable size in memory allocation in xt_hashlimit,
         from Zhizhou Tian.
      
      8) Fix build/link problems with hashlimit and 32-bit arches, to address
         recent fallout from a new hashlimit mode, from Vishwanath Pai.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      10807461
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2017-09-08' of... · 91aac563
      David S. Miller authored
      
      Merge tag 'wireless-drivers-for-davem-2017-09-08' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.14
      
      Few fixes to regressions introduced in the last one or two releases.
      The iwlwifi fix is for a regression reported by Linus.
      
      rtlwifi
      
      * fix two antenna selection related bugs
      
      iwlwifi
      
      * fix regression with older firmwares
      
      brcmfmac
      
      * workaround firmware crash for bcm4345
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      91aac563
    • Marcelo Ricardo Leitner's avatar
      sctp: fix missing wake ups in some situations · 7906b00f
      Marcelo Ricardo Leitner authored
      Commit fb586f25 ("sctp: delay calls to sk_data_ready() as much as
      possible") minimized the number of wake ups that are triggered in case
      the association receives a packet with multiple data chunks on it and/or
      when io_events are enabled and then commit 0970f5b3 ("sctp: signal
      sk_data_ready earlier on data chunks reception") moved the wake up to as
      soon as possible. It thus relies on the state machine running later to
      clean the flag that the event was already generated.
      
      The issue is that there are 2 call paths that calls
      sctp_ulpq_tail_event() outside of the state machine, causing the flag to
      linger and possibly omitting a needed wake up in the sequence.
      
      One of the call paths is when enabling SCTP_SENDER_DRY_EVENTS via
      setsockopt(SCTP_EVENTS), as noticed by Harald Welte. The other is when
      partial reliability triggers removal of chunks from the send queue when
      the application calls sendmsg().
      
      This commit fixes it by not setting the flag in case the socket is not
      owned by the user, as it won't be cleaned later. This works for
      user-initiated calls and also for rx path processing.
      
      Fixes: fb586f25
      
       ("sctp: delay calls to sk_data_ready() as much as possible")
      Reported-by: default avatarHarald Welte <laforge@gnumonks.org>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7906b00f
    • Vishwanath Pai's avatar
      netfilter: xt_hashlimit: fix build error caused by 64bit division · 90c4ae4e
      Vishwanath Pai authored
      64bit division causes build/link errors on 32bit architectures. It
      prints out error messages like:
      
      ERROR: "__aeabi_uldivmod" [net/netfilter/xt_hashlimit.ko] undefined!
      
      The value of avg passed through by userspace in BYTE mode cannot exceed
      U32_MAX. Which means 64bit division in user2rate_bytes is unnecessary.
      To fix this I have changed the type of param 'user' to u32.
      
      Since anything greater than U32_MAX is an invalid input we error out in
      hashlimit_mt_check_common() when this is the case.
      
      Changes in v2:
      	Making return type as u32 would cause an overflow for small
      	values of 'user' (for example 2, 3 etc). To avoid this I bumped up
      	'r' to u64 again as well as the return type. This is OK since the
      	variable that stores the result is u64. We still avoid 64bit
      	division here since 'user' is u32.
      
      Fixes: bea74641
      
       ("netfilter: xt_hashlimit: add rate match mode")
      Signed-off-by: default avatarVishwanath Pai <vpai@akamai.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      90c4ae4e
    • Zhizhou Tian's avatar
      netfilter: xt_hashlimit: alloc hashtable with right size · 05d0eae7
      Zhizhou Tian authored
      
      
      struct xt_byteslimit_htable used hlist_head, but memory allocation is
      done through sizeof(struct list_head).
      
      Signed-off-by: default avatarZhizhou Tian <zhizhou.tian@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      05d0eae7
    • Florian Westphal's avatar
      netfilter: core: remove erroneous warn_on · 74585d4f
      Florian Westphal authored
      kernel test robot reported:
      
      WARNING: CPU: 0 PID: 1244 at net/netfilter/core.c:218 __nf_hook_entries_try_shrink+0x49/0xcd
      [..]
      
      After allowing batching in nf_unregister_net_hooks its possible that an earlier
      call to __nf_hook_entries_try_shrink already compacted the list.
      If this happens we don't need to do anything.
      
      Fixes: d3ad2c17
      
       ("netfilter: core: batch nf_unregister_net_hooks synchronize_net calls")
      Reported-by: default avatarkernel test robot <xiaolong.ye@intel.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarAaron Conole <aconole@bytheb.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      74585d4f
    • Florian Westphal's avatar
      netfilter: nat: use keyed locks · 8073e960
      Florian Westphal authored
      
      
      no need to serialize on a single lock, we can partition the table and
      add/delete in parallel to different slots.
      This restores one of the advantages that got lost with the rhlist
      revert.
      
      Cc: Ivan Babrou <ibobrik@gmail.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      8073e960
    • Florian Westphal's avatar
      netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable" · e1bf1687
      Florian Westphal authored
      This reverts commit 870190a9
      
      .
      
      It was not a good idea. The custom hash table was a much better
      fit for this purpose.
      
      A fast lookup is not essential, in fact for most cases there is no lookup
      at all because original tuple is not taken and can be used as-is.
      What needs to be fast is insertion and deletion.
      
      rhlist removal however requires a rhlist walk.
      We can have thousands of entries in such a list if source port/addresses
      are reused for multiple flows, if this happens removal requests are so
      expensive that deletions of a few thousand flows can take several
      seconds(!).
      
      The advantages that we got from rhashtable are:
      1) table auto-sizing
      2) multiple locks
      
      1) would be nice to have, but it is not essential as we have at
      most one lookup per new flow, so even a million flows in the bysource
      table are not a problem compared to current deletion cost.
      2) is easy to add to custom hash table.
      
      I tried to add hlist_node to rhlist to speed up rhltable_remove but this
      isn't doable without changing semantics.  rhltable_remove_fast will
      check that the to-be-deleted object is part of the table and that
      requires a list walk that we want to avoid.
      
      Furthermore, using hlist_node increases size of struct rhlist_head, which
      in turn increases nf_conn size.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=196821
      Reported-by: default avatarIvan Babrou <ibobrik@gmail.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      e1bf1687
    • Florian Westphal's avatar
      netfilter: xtables: add scheduling opportunity in get_counters · a5d7a714
      Florian Westphal authored
      
      
      There are reports about spurious softlockups during iptables-restore, a
      backtrace i saw points at get_counters -- it uses a sequence lock and also
      has unbounded restart loop.
      
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      a5d7a714
    • Florian Westphal's avatar
      netfilter: nf_nat: don't bug when mapping already exists · 75c26314
      Florian Westphal authored
      
      
      It seems preferrable to limp along if we have a conflicting mapping,
      its certainly better than a BUG().
      
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      75c26314
    • Sabrina Dubroca's avatar
      ipv6: fix memory leak with multiple tables during netns destruction · ba1cc08d
      Sabrina Dubroca authored
      
      
      fib6_net_exit only frees the main and local tables. If another table was
      created with fib6_alloc_table, we leak it when the netns is destroyed.
      
      Fix this in the same way ip_fib_net_exit cleans up tables, by walking
      through the whole hashtable of fib6_table's. We can get rid of the
      special cases for local and main, since they're also part of the
      hashtable.
      
      Reproducer:
          ip netns add x
          ip -net x -6 rule add from 6003:1::/64 table 100
          ip netns del x
      
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Fixes: 58f09b78
      
       ("[NETNS][IPV6] ip6_fib - make it per network namespace")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba1cc08d
  2. Sep 08, 2017
  3. Sep 07, 2017