1. 29 Oct, 2016 1 commit
  2. 28 Oct, 2016 3 commits
  3. 27 Oct, 2016 11 commits
    • Jamal Hadi Salim's avatar
      net sched filters: fix notification of filter delete with proper handle · 9ee78374
      Jamal Hadi Salim authored
      Daniel says:
      While trying out [1][2], I noticed that tc monitor doesn't show the
      correct handle on delete:
      $ tc monitor
      qdisc clsact ffff: dev eno1 parent ffff:fff1
      filter dev eno1 ingress protocol all pref 49152 bpf handle 0x2a [...]
      deleted filter dev eno1 ingress protocol all pref 49152 bpf handle 0xf3be0c80
      some context to explain the above:
      The user identity of any tc filter is represented by a 32-bit
      identifier encoded in tcm->tcm_handle. Example 0x2a in the bpf filter
      above. A user wishing to delete, get or even modify a specific filter
      uses this handle to reference it.
      Every classifier is free to provide its own semantics for the 32 bit handle.
      Example: classifiers like u32 use schemes like 800:1:801 to describe
      the semantics of their filters represented as hash table, bucket and
      node ids etc.
      Classifiers also have internal per-filter representation which is different
      from this externally visible identity. Most classifiers set this
      internal representation to be a pointer address (which allows fast retrieval
      of said filters in their implementations). This internal representation
      is referenced with the "fh" variable in the kernel control code.
      When a user successfuly deletes a specific filter, by specifying the correct
      tcm->tcm_handle, an event is generated to user space which indicates
      which specific filter was deleted.
      Before this patch, the "fh" value was sent to user space as the identity.
      As an example what is shown in the sample bpf filter delete event above
      is 0xf3be0c80. This is infact a 32-bit truncation of 0xffff8807f3be0c80
      which happens to be a 64-bit memory address of the internal filter
      representation (address of the corresponding filter's struct cls_bpf_prog);
      After this patch the appropriate user identifiable handle as encoded
      in the originating request tcm->tcm_handle is generated in the event.
      One of the cardinal rules of netlink rules is to be able to take an
      event (such as a delete in this case) and reflect it back to the
      kernel and successfully delete the filter. This patch achieves that.
      Note, this issue has existed since the original TC action
      infrastructure code patch back in 2004 as found in:
      [1] http://patchwork.ozlabs.org/patch/682828/
      [2] http://patchwork.ozlabs.org/patch/682829/
      Fixes: 4e54c4816bfe ("[NET]: Add tc extensions infrastructure.")
      Reported-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Colin Ian King's avatar
      net: bgmac: fix spelling mistake: "connecton" -> "connection" · c121f72a
      Colin Ian King authored
      trivial fix to spelling mistake in dev_err message
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Acked-by: default avatarJon Mason <jon.mason@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Arnd Bergmann's avatar
      flow_dissector: fix vlan tag handling · bc72f3dd
      Arnd Bergmann authored
      gcc warns about an uninitialized pointer dereference in the vlan
      priority handling:
      net/core/flow_dissector.c: In function '__skb_flow_dissect':
      net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      As pointed out by Jiri Pirko, the variable is never actually used
      without being initialized first as the only way it end up uninitialized
      is with skb_vlan_tag_present(skb)==true, and that means it does not
      get accessed.
      However, the warning hints at some related issues that I'm addressing
      - the second check for the vlan tag is different from the first one
        that tests the skb for being NULL first, causing both the warning
        and a possible NULL pointer dereference that was not entirely fixed.
      - The same patch that introduced the NULL pointer check dropped an
        earlier optimization that skipped the repeated check of the
        protocol type
      - The local '_vlan' variable is referenced through the 'vlan' pointer
        but the variable has gone out of scope by the time that it is
        accessed, causing undefined behavior
      Caching the result of the 'skb && skb_vlan_tag_present(skb)' check
      in a local variable allows the compiler to further optimize the
      later check. With those changes, the warning also disappears.
      Fixes: 3805a938 ("flow_dissector: Check skb for VLAN only if skb specified.")
      Fixes: d5709f7a
       ("flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Acked-by: default avatarEric Garver <e@erig.me>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David Ahern's avatar
      net: ipv6: Do not consider link state for nexthop validation · d5d32e4b
      David Ahern authored
      Similar to IPv4, do not consider link state when validating next hops.
      Currently, if the link is down default routes can fail to insert:
       $ ip -6 ro add vrf blue default via 2100:2::64 dev eth2
       RTNETLINK answers: No route to host
      With this patch the command succeeds.
      Fixes: 8c14586f
       ("net: ipv6: Use passed in table for nexthop lookups")
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David Ahern's avatar
      net: ipv6: Fix processing of RAs in presence of VRF · 830218c1
      David Ahern authored
      rt6_add_route_info and rt6_add_dflt_router were updated to pull the FIB
      table from the device index, but the corresponding rt6_get_route_info
      and rt6_get_dflt_router functions were not leading to the failure to
      process RA's:
          ICMPv6: RA: ndisc_router_discovery failed to add default route
      Fix the 'get' functions by using the table id associated with the
      device when applicable.
      Also, now that default routes can be added to tables other than the
      default table, rt6_purge_dflt_routers needs to be updated as well to
      look at all tables. To handle that efficiently, add a flag to the table
      denoting if it is has a default route via RA.
      Fixes: ca254490
       ("net: Add VRF support to IPv6 stack")
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Arnd Bergmann's avatar
      kalmia: avoid potential uninitialized variable use · e30520c2
      Arnd Bergmann authored
      The kalmia_send_init_packet() returns zero or a negative return
      code, but gcc has no way of knowing that there cannot be a
      positive return code, so it determines that copying the ethernet
      address at the end of kalmia_bind() will access uninitialized
      drivers/net/usb/kalmia.c: In function ‘kalmia_bind’:
      arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)&ethernet_addr+4)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
         *((short *)to + 2) = *((short *)from + 2);
      drivers/net/usb/kalmia.c:138:5: note: ‘*((void *)&ethernet_addr+4)’ was declared here
      This warning is harmless, but for consistency, we should make
      the check for the return code match what the driver does everywhere
      else and just progate it, which then gets rid of the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Tobias Brunner's avatar
      macsec: Fix header length if SCI is added if explicitly disabled · e0f841f5
      Tobias Brunner authored
      Even if sending SCIs is explicitly disabled, the code that creates the
      Security Tag might still decide to add it (e.g. if multiple RX SCs are
      defined on the MACsec interface).
      But because the header length so far only depended on the configuration
      option the SCI overwrote the original frame's contents (EtherType and
      e.g. the beginning of the IP header) and if encrypted did not visibly
      end up in the packet, while the SC flag in the TCI field of the Security
      Tag was still set, resulting in invalid MACsec frames.
      Fixes: c09440f7
       ("macsec: introduce IEEE 802.1AE driver")
      Signed-off-by: default avatarTobias Brunner <tobias@strongswan.org>
      Acked-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Zefir Kurtisi's avatar
      at803x: double check SGMII side autoneg · f62265b5
      Zefir Kurtisi authored
      In SGMII mode, we observed an autonegotiation issue
      after power-down-up cycles where the copper side
      reports successful link establishment but the
      SGMII side's link is down.
      This happened in a setup where the at8031 is
      connected over SGMII to a eTSEC (fsl gianfar),
      but so far could not be reproduced with other
      Ethernet device / driver combinations.
      This commit adds a wrapper function for at8031
      that in case of operating in SGMII mode double
      checks SGMII link state when generic aneg_done()
      succeeds. It prints a warning on failure but
      intentionally does not try to recover from this
      state. As a result, if you ever see a warning
      '803x_aneg_done: SGMII link is not ok' you will
      end up having an Ethernet link up but won't get
      any data through. This should not happen, if it
      does, please contact the module maintainer.
      Signed-off-by: default avatarZefir Kurtisi <zefir.kurtisi@neratec.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Zefir Kurtisi's avatar
      Revert "at803x: fix suspend/resume for SGMII link" · 4fc6d239
      Zefir Kurtisi authored
      This reverts commit 98267311
      Suspending the SGMII alongside the copper side
      made the at803x inaccessable while powered down,
      e.g. it can't be re-probed after suspend.
      Signed-off-by: default avatarZefir Kurtisi <zefir.kurtisi@neratec.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Mintz, Yuval's avatar
      MAINTAINERS: Update qlogic networking drivers · 67f0160f
      Mintz, Yuval authored
      Following Cavium's acquisition of qlogic we need to update all the qlogic
      drivers maintainer's entries to point to our new e-mail addresses,
      as well as update some of the driver's maintainers as those are no longer
      working for Cavium.
      I would like to thank Sony Chacko and Rajesh Borundia for their support
      and development of our various networking drivers.
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Stephen Hemminger's avatar
      netvsc: fix incorrect receive checksum offloading · e52fed71
      Stephen Hemminger authored
      The Hyper-V netvsc driver was looking at the incorrect status bits
      in the checksum info. It was setting the receive checksum unnecessary
      flag based on the IP header checksum being correct. The checksum
      flag is skb is about TCP and UDP checksum status. Because of this
      bug, any packet received with bad TCP checksum would be passed
      up the stack and to the application causing data corruption.
      The problem is reproducible via netcat and netem.
      This had a side effect of not doing receive checksum offload
      on IPv6. The driver was also also always doing checksum offload
      independent of the checksum setting done via ethtool.
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 26 Oct, 2016 4 commits
  5. 23 Oct, 2016 5 commits
    • David S. Miller's avatar
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth · 44060abe
      David S. Miller authored
      Johan Hedberg says:
      pull request: bluetooth 2016-10-21
      Here are some more Bluetooth fixes for the 4.9 kernel:
       - Fix to btwilink driver probe function return value
       - Power management fix to hci_bcm
       - Fix to encoding name in scan response data
      Please let me know if there are any issues pulling. Thanks.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jiri Slaby's avatar
      net: sctp, forbid negative length · a4b8e71b
      Jiri Slaby authored
      Most of getsockopt handlers in net/sctp/socket.c check len against
      sizeof some structure like:
              if (len < sizeof(int))
                      return -EINVAL;
      On the first look, the check seems to be correct. But since len is int
      and sizeof returns size_t, int gets promoted to unsigned size_t too. So
      the test returns false for negative lengths. Yes, (-1 < sizeof(long)) is
      Fix this in sctp by explicitly checking len < 0 before any getsockopt
      handler is called.
      Note that sctp_getsockopt_events already handled the negative case.
      Since we added the < 0 check elsewhere, this one can be removed.
      If not checked, this is the result:
      UBSAN: Undefined behaviour in ../mm/page_alloc.c:2722:19
      shift exponent 52 is too large for 32-bit type 'int'
      CPU: 1 PID: 24535 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
       0000000000000000 ffff88006d99f2a8 ffffffffb2f7bdea 0000000041b58ab3
       ffffffffb4363c14 ffffffffb2f7bcde ffff88006d99f2d0 ffff88006d99f270
       0000000000000000 0000000000000000 0000000000000034 ffffffffb5096422
      Call Trace:
       [<ffffffffb3051498>] ? __ubsan_handle_shift_out_of_bounds+0x29c/0x300
       [<ffffffffb273f0e4>] ? kmalloc_order+0x24/0x90
       [<ffffffffb27416a4>] ? kmalloc_order_trace+0x24/0x220
       [<ffffffffb2819a30>] ? __kmalloc+0x330/0x540
       [<ffffffffc18c25f4>] ? sctp_getsockopt_local_addrs+0x174/0xca0 [sctp]
       [<ffffffffc18d2bcd>] ? sctp_getsockopt+0x10d/0x1b0 [sctp]
       [<ffffffffb37c1219>] ? sock_common_getsockopt+0xb9/0x150
       [<ffffffffb37be2f5>] ? SyS_getsockopt+0x1a5/0x270
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-sctp@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Fabio Estevam's avatar
      net: fec: Call swap_buffer() prior to IP header alignment · 235bde1e
      Fabio Estevam authored
      Commit 3ac72b7b ("net: fec: align IP header in hardware") breaks
      networking on mx28.
      There is an erratum on mx28 (ENGR121613 - ENET big endian mode
      not compatible with ARM little endian) that requires an additional
      byte-swap operation to workaround this problem.
      So call swap_buffer() prior to performing the IP header alignment
      to restore network functionality on mx28.
      Fixes: 3ac72b7b
       ("net: fec: align IP header in hardware")
      Reported-and-tested-by: default avatarHenri Roosen <henri.roosen@ginzinger.com>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jason A. Donenfeld's avatar
      ipv6: do not increment mac header when it's unset · b678aa57
      Jason A. Donenfeld authored
      Otherwise we'll overflow the integer. This occurs when layer 3 tunneled
      packets are handed off to the IPv6 layer.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Sudarsana Reddy Kalluru's avatar
      bnx2x: Use the correct divisor value for PHC clock readings. · a6e2846c
      Sudarsana Reddy Kalluru authored
      Time Sync (PTP) implementation uses the divisor/shift value for converting
      the clock ticks to nanoseconds. Driver currently defines shift value as 1,
      this results in the nanoseconds value to be calculated as half the actual
      value. Hence the user application fails to synchronize the device clock
      value with the PTP master device clock. Need to use the 'shift' value of 0.
      Signed-off-by: default avatarSony.Chacko <Sony.Chacko@cavium.com>
      Signed-off-by: default avatarSudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  6. 22 Oct, 2016 13 commits
  7. 21 Oct, 2016 3 commits
    • WANG Cong's avatar
      ipv6: fix a potential deadlock in do_ipv6_setsockopt() · 8651be8f
      WANG Cong authored
      Baozeng reported this deadlock case:
             CPU0                    CPU1
             ----                    ----
        lock([  165.136033] sk_lock-AF_INET6);
                                     lock([  165.136033] rtnl_mutex);
                                     lock([  165.136033] sk_lock-AF_INET6);
        lock([  165.136033] rtnl_mutex);
      Similar to commit 87e9f031
      ("ipv4: fix a potential deadlock in mcast getsockopt() path")
      this is due to we still have a case, ipv6_sock_mc_close(),
      where we acquire sk_lock before rtnl_lock. Close this deadlock
      with the similar solution, that is always acquire rtnl lock first.
      Fixes: baf606d9
       ("ipv4,ipv6: grab rtnl before locking the socket")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Tested-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 8dbad1a8
      David S. Miller authored
      Pablo Neira Ayuso says:
      Netfilter fixes for net
      The following patchset contains Netfilter fixes for your net tree,
      they are:
      1) Fix compilation warning in xt_hashlimit on m68k 32-bits, from
         Geert Uytterhoeven.
      2) Fix wrong timeout in set elements added from packet path via
         nft_dynset, from Anders K. Pedersen.
      3) Remove obsolete nf_conntrack_events_retry_timeout sysctl
         documentation, from Nicolas Dichtel.
      4) Ensure proper initialization of log flags via xt_LOG, from
         Liping Zhang.
      5) Missing alias to autoload ipcomp, also from Liping Zhang.
      6) Missing NFTA_HASH_OFFSET attribute validation, again from Liping.
      7) Wrong integer type in the new nft_parse_u32_check() function,
         from Dan Carpenter.
      8) Another wrong integer type declaration in nft_exthdr_init, also
         from Dan Carpenter.
      9) Fix insufficient mode validation in nft_range.
      10) Fix compilation warning in nft_range due to possible uninitialized
          value, from Arnd Bergmann.
      11) Zero nf_hook_ops allocated via xt_hook_alloc() in x_tables to
          calm down kmemcheck, from Florian Westphal.
      12) Schedule gc_worker() to run again if GC_MAX_EVICTS quota is reached,
          from Nicolas Dichtel.
      13) Fix nf_queue() after conversion to single-linked hook list, related
          to incorrect bypass flag handling and incorrect hook point of
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Florian Fainelli's avatar
      kexec: Export kexec_in_progress to modules · 97dcaa0f
      Florian Fainelli authored
      The bcm_sf2 driver uses kexec_in_progress to know whether it can power
      down an integrated PHY during shutdown, and can be built as a module.
      Other modules may be using this in the future, so export it.
      Fixes: 2399d614
       ("net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>