1. 01 Apr, 2016 5 commits
    • Giuseppe CAVALLARO's avatar
      stmmac: fix TX normal DESC · a00e3ab6
      Giuseppe CAVALLARO authored
      This patch fixs a regression raised when test on chips that use
      the normal descriptor layout. In fact, no len bits were set for
      the TDES1 and no OWN bit inside the TDES0.
      Signed-off-by: default avatarGiuseppe CAVALLARO <peppe.cavallaro@st.com>
      Tested-by: default avatarAndreas Färber <afaerber@suse.de>
      Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a00e3ab6
    • Jisheng Zhang's avatar
      net: mvneta: use cache_line_size() to get cacheline size · c66e98c9
      Jisheng Zhang authored
      L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
      to determine the cacheline size in runtime.
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Suggested-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c66e98c9
    • Jisheng Zhang's avatar
      net: mvpp2: use cache_line_size() to get cacheline size · 4a0a12d2
      Jisheng Zhang authored
      L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
      to determine the cacheline size in runtime.
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Suggested-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a0a12d2
    • Jisheng Zhang's avatar
      net: mvpp2: fix maybe-uninitialized warning · d82b0c21
      Jisheng Zhang authored
      This is to fix the following maybe-uninitialized warning:
      
      drivers/net/ethernet/marvell/mvpp2.c:6007:18: warning: 'err' may be
      used uninitialized in this function [-Wmaybe-uninitialized]
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d82b0c21
    • Daniel Borkmann's avatar
      tun, bpf: fix suspicious RCU usage in tun_{attach, detach}_filter · 5a5abb1f
      Daniel Borkmann authored
      Sasha Levin reported a suspicious rcu_dereference_protected() warning
      found while fuzzing with trinity that is similar to this one:
      
        [   52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage!
        [   52.765688] other info that might help us debug this:
        [   52.765695] rcu_scheduler_active = 1, debug_locks = 1
        [   52.765701] 1 lock held by a.out/1525:
        [   52.765704]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff816a64b7>] rtnl_lock+0x17/0x20
        [   52.765721] stack backtrace:
        [   52.765728] CPU: 1 PID: 1525 Comm: a.out Not tainted 4.5.0+ #264
        [...]
        [   52.765768] Call Trace:
        [   52.765775]  [<ffffffff813e488d>] dump_stack+0x85/0xc8
        [   52.765784]  [<ffffffff810f2fa5>] lockdep_rcu_suspicious+0xd5/0x110
        [   52.765792]  [<ffffffff816afdc2>] sk_detach_filter+0x82/0x90
        [   52.765801]  [<ffffffffa0883425>] tun_detach_filter+0x35/0x90 [tun]
        [   52.765810]  [<ffffffffa0884ed4>] __tun_chr_ioctl+0x354/0x1130 [tun]
        [   52.765818]  [<ffffffff8136fed0>] ? selinux_file_ioctl+0x130/0x210
        [   52.765827]  [<ffffffffa0885ce3>] tun_chr_ioctl+0x13/0x20 [tun]
        [   52.765834]  [<ffffffff81260ea6>] do_vfs_ioctl+0x96/0x690
        [   52.765843]  [<ffffffff81364af3>] ? security_file_ioctl+0x43/0x60
        [   52.765850]  [<ffffffff81261519>] SyS_ioctl+0x79/0x90
        [   52.765858]  [<ffffffff81003ba2>] do_syscall_64+0x62/0x140
        [   52.765866]  [<ffffffff817d563f>] entry_SYSCALL64_slow_path+0x25/0x25
      
      Same can be triggered with PROVE_RCU (+ PROVE_RCU_REPEATEDLY) enabled
      from tun_attach_filter() when user space calls ioctl(tun_fd, TUN{ATTACH,
      DETACH}FILTER, ...) for adding/removing a BPF filter on tap devices.
      
      Since the fix in f91ff5b9 ("net: sk_{detach|attach}_filter() rcu
      fixes") sk_attach_filter()/sk_detach_filter() now dereferences the
      filter with rcu_dereference_protected(), checking whether socket lock
      is held in control path.
      
      Since its introduction in 99405162 ("tun: socket filter support"),
      tap filters are managed under RTNL lock from __tun_chr_ioctl(). Thus the
      sock_owned_by_user(sk) doesn't apply in this specific case and therefore
      triggers the false positive.
      
      Extend the BPF API with __sk_attach_filter()/__sk_detach_filter() pair
      that is used by tap filters and pass in lockdep_rtnl_is_held() for the
      rcu_dereference_protected() checks instead.
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a5abb1f
  2. 31 Mar, 2016 8 commits
  3. 30 Mar, 2016 22 commits
  4. 29 Mar, 2016 1 commit
    • Bjørn Mork's avatar
      qmi_wwan: add "D-Link DWM-221 B1" device id · e84810c7
      Bjørn Mork authored
      Thomas reports:
      "Windows:
      
      00 diagnostics
      01 modem
      02 at-port
      03 nmea
      04 nic
      
      Linux:
      
      T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2001 ProdID=7e19 Rev=02.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
      Reported-by: default avatarThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e84810c7
  5. 28 Mar, 2016 4 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 0c84ea17
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for you net tree,
      they are:
      
      1) There was a race condition between parallel save/swap and delete,
         which resulted a kernel crash due to the increase ref for save, swap,
         wrong ref decrease operations. Reported and fixed by Vishwanath Pai.
      
      2) OVS should call into CT NAT for packets of new expected connections only
         when the conntrack state is persisted with the 'commit' option to the
         OVS CT action. From Jarno Rajahalme.
      
      3) Resolve kconfig dependencies with new OVS NAT support. From Arnd Bergmann.
      
      4) Early validation of entry->target_offset to make sure it doesn't take us
         out from the blob, from Florian Westphal.
      
      5) Again early validation of entry->next_offset to make sure it doesn't take
         out from the blob, also from Florian.
      
      6) Check that entry->target_offset is always of of sizeof(struct xt_entry)
         for unconditional entries, when checking both from check_underflow()
         and when checking for loops in mark_source_chains(), again from
         Florian.
      
      7) Fix inconsistent behaviour in nfnetlink_queue when
         NFQA_CFG_F_FAIL_OPEN is set and netlink_unicast() fails due to buffer
         overrun, we have to reinject the packet as the user expects.
      
      8) Enforce nul-terminated table names from getsockopt GET_ENTRIES
         requests.
      
      9) Don't assume skb->sk is set from nft_bridge_reject and synproxy,
         this fixes a recent update of the code to namespaceify
         ip_default_ttl, patch from Liping Zhang.
      
      This batch comes with four patches to validate x_tables blobs coming
      from userspace. CONFIG_USERNS exposes the x_tables interface to
      unpriviledged users and to be honest this interface never received the
      attention for this move away from the CAP_NET_ADMIN domain. Florian is
      working on another round with more patches with more sanity checks, so
      expect a bit more Netfilter fixes in this development cycle than usual.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c84ea17
    • Liping Zhang's avatar
      netfilter: ipv4: fix NULL dereference · 29421198
      Liping Zhang authored
      Commit fa50d974 ("ipv4: Namespaceify ip_default_ttl sysctl knob")
      use sock_net(skb->sk) to get the net namespace, but we can't assume
      that sk_buff->sk is always exist, so when it is NULL, oops will happen.
      Signed-off-by: default avatarLiping Zhang <liping.zhang@spreadtrum.com>
      Reviewed-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      29421198
    • Pablo Neira Ayuso's avatar
      netfilter: x_tables: enforce nul-terminated table name from getsockopt GET_ENTRIES · b301f253
      Pablo Neira Ayuso authored
      Make sure the table names via getsockopt GET_ENTRIES is nul-terminated
      in ebtables and all the x_tables variants and their respective compat
      code. Uncovered by KASAN.
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      b301f253
    • Pablo Neira Ayuso's avatar
      netfilter: nfnetlink_queue: honor NFQA_CFG_F_FAIL_OPEN when netlink unicast fails · 93140113
      Pablo Neira Ayuso authored
      When netlink unicast fails to deliver the message to userspace, we
      should also check if the NFQA_CFG_F_FAIL_OPEN flag is set so we reinject
      the packet back to the stack.
      
      I think the user expects no packet drops when this flag is set due to
      queueing to userspace errors, no matter if related to the internal queue
      or when sending the netlink message to userspace.
      
      The userspace application will still get the ENOBUFS error via recvmsg()
      so the user still knows that, with the current configuration that is in
      place, the userspace application is not consuming the messages at the
      pace that the kernel needs.
      Reported-by: default avatar"Yigal Reiss (yreiss)" <yreiss@cisco.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Tested-by: default avatar"Yigal Reiss (yreiss)" <yreiss@cisco.com>
      93140113