1. 18 10月, 2017 1 次提交
    • K
      net: hns: Convert timers to use timer_setup() · d039ef68
      Kees Cook 提交于
      In preparation for unconditionally passing the struct timer_list pointer to
      all timer callbacks, switch to using the new timer_setup() and from_timer()
      to pass the timer pointer explicitly. Switches test of .data field to
      .function, since .data will be going away.
      
      Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
      Cc: Salil Mehta <salil.mehta@huawei.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: lipeng <lipeng321@huawei.com>
      Cc: Lin Yun Sheng <linyunsheng@huawei.com>
      Cc: Kejian Yan <yankejian@huawei.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d039ef68
  2. 05 8月, 2017 1 次提交
  3. 04 8月, 2017 1 次提交
  4. 20 7月, 2017 1 次提交
  5. 14 7月, 2017 1 次提交
  6. 12 7月, 2017 1 次提交
  7. 08 7月, 2017 1 次提交
    • Y
      net: hns: Fix a skb used after free bug · 27463ad9
      Yunsheng Lin 提交于
      skb maybe freed in hns_nic_net_xmit_hw() and return NETDEV_TX_OK,
      which cause hns_nic_net_xmit to use a freed skb.
      
      BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x62c/0x940...
      	[17659.112635]      alloc_debug_processing+0x18c/0x1a0
      	[17659.117208]      __slab_alloc+0x52c/0x560
      	[17659.120909]      kmem_cache_alloc_node+0xac/0x2c0
      	[17659.125309]      __alloc_skb+0x6c/0x260
      	[17659.128837]      tcp_send_ack+0x8c/0x280
      	[17659.132449]      __tcp_ack_snd_check+0x9c/0xf0
      	[17659.136587]      tcp_rcv_established+0x5a4/0xa70
      	[17659.140899]      tcp_v4_do_rcv+0x27c/0x620
      	[17659.144687]      tcp_prequeue_process+0x108/0x170
      	[17659.149085]      tcp_recvmsg+0x940/0x1020
      	[17659.152787]      inet_recvmsg+0x124/0x180
      	[17659.156488]      sock_recvmsg+0x64/0x80
      	[17659.160012]      SyS_recvfrom+0xd8/0x180
      	[17659.163626]      __sys_trace_return+0x0/0x4
      	[17659.167506] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=23 cpu=1 pid=13
      	[17659.174000]      free_debug_processing+0x1d4/0x2c0
      	[17659.178486]      __slab_free+0x240/0x390
      	[17659.182100]      kmem_cache_free+0x24c/0x270
      	[17659.186062]      kfree_skbmem+0xa0/0xb0
      	[17659.189587]      __kfree_skb+0x28/0x40
      	[17659.193025]      napi_gro_receive+0x168/0x1c0
      	[17659.197074]      hns_nic_rx_up_pro+0x58/0x90
      	[17659.201038]      hns_nic_rx_poll_one+0x518/0xbc0
      	[17659.205352]      hns_nic_common_poll+0x94/0x140
      	[17659.209576]      net_rx_action+0x458/0x5e0
      	[17659.213363]      __do_softirq+0x1b8/0x480
      	[17659.217062]      run_ksoftirqd+0x64/0x80
      	[17659.220679]      smpboot_thread_fn+0x224/0x310
      	[17659.224821]      kthread+0x150/0x170
      	[17659.228084]      ret_from_fork+0x10/0x40
      
      	BUG: KASAN: use-after-free in hns_nic_net_xmit+0x8c/0xc0...
      	[17751.080490]      __slab_alloc+0x52c/0x560
      	[17751.084188]      kmem_cache_alloc+0x244/0x280
      	[17751.088238]      __build_skb+0x40/0x150
      	[17751.091764]      build_skb+0x28/0x100
      	[17751.095115]      __alloc_rx_skb+0x94/0x150
      	[17751.098900]      __napi_alloc_skb+0x34/0x90
      	[17751.102776]      hns_nic_rx_poll_one+0x180/0xbc0
      	[17751.107097]      hns_nic_common_poll+0x94/0x140
      	[17751.111333]      net_rx_action+0x458/0x5e0
      	[17751.115123]      __do_softirq+0x1b8/0x480
      	[17751.118823]      run_ksoftirqd+0x64/0x80
      	[17751.122437]      smpboot_thread_fn+0x224/0x310
      	[17751.126575]      kthread+0x150/0x170
      	[17751.129838]      ret_from_fork+0x10/0x40
      	[17751.133454] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=19 cpu=7 pid=43
      	[17751.139951]      free_debug_processing+0x1d4/0x2c0
      	[17751.144436]      __slab_free+0x240/0x390
      	[17751.148051]      kmem_cache_free+0x24c/0x270
      	[17751.152014]      kfree_skbmem+0xa0/0xb0
      	[17751.155543]      __kfree_skb+0x28/0x40
      	[17751.159022]      napi_gro_receive+0x168/0x1c0
      	[17751.163074]      hns_nic_rx_up_pro+0x58/0x90
      	[17751.167041]      hns_nic_rx_poll_one+0x518/0xbc0
      	[17751.171358]      hns_nic_common_poll+0x94/0x140
      	[17751.175585]      net_rx_action+0x458/0x5e0
      	[17751.179373]      __do_softirq+0x1b8/0x480
      	[17751.183076]      run_ksoftirqd+0x64/0x80
      	[17751.186691]      smpboot_thread_fn+0x224/0x310
      	[17751.190826]      kthread+0x150/0x170
      	[17751.194093]      ret_from_fork+0x10/0x40
      
      Fixes: 13ac695e ("net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem")
      Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: Nlipeng <lipeng321@huawei.com>
      Reported-by: NJun He <hjat2005@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27463ad9
  8. 03 7月, 2017 1 次提交
  9. 27 6月, 2017 1 次提交
  10. 20 6月, 2017 1 次提交
  11. 14 6月, 2017 1 次提交
  12. 07 6月, 2017 1 次提交
  13. 09 5月, 2017 1 次提交
    • K
      format-security: move static strings to const · 06324664
      Kees Cook 提交于
      While examining output from trial builds with -Wformat-security enabled,
      many strings were found that should be defined as "const", or as a char
      array instead of char pointer.  This makes some static analysis easier,
      by producing fewer false positives.
      
      As these are all trivial changes, it seemed best to put them all in a
      single patch rather than chopping them up per maintainer.
      
      Link: http://lkml.kernel.org/r/20170405214711.GA5711@beastSigned-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: Jes Sorensen <jes@trained-monkey.org>	[runner.c]
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
      Cc: Salil Mehta <salil.mehta@huawei.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Patrice Chotard <patrice.chotard@st.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
      Cc: Jarod Wilson <jarod@redhat.com>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Antonio Quartulli <a@unstable.cc>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Kejian Yan <yankejian@huawei.com>
      Cc: Daode Huang <huangdaode@hisilicon.com>
      Cc: Qianqian Xie <xieqianqian@huawei.com>
      Cc: Philippe Reynes <tremyfr@gmail.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Christian Gromm <christian.gromm@microchip.com>
      Cc: Andrey Shvetsov <andrey.shvetsov@k2l.de>
      Cc: Jason Litzinger <jlitzingerdev@gmail.com>
      Cc: WANG Cong <xiyou.wangcong@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      06324664
  14. 03 5月, 2017 1 次提交
    • T
      net: hns: fix ethtool_get_strings overflow in hns driver · 412b65d1
      Timmy Li 提交于
      hns_get_sset_count() returns HNS_NET_STATS_CNT and the data space allocated
      is not enough for ethtool_get_strings(), which will cause random memory
      corruption.
      
      When SLAB and DEBUG_SLAB are both enabled, memory corruptions like the
      the following can be observed without this patch:
      [   43.115200] Slab corruption (Not tainted): Acpi-ParseExt start=ffff801fb0b69030, len=80
      [   43.115206] Redzone: 0x9f911029d006462/0x5f78745f31657070.
      [   43.115208] Last user: [<5f7272655f746b70>](0x5f7272655f746b70)
      [   43.115214] 010: 70 70 65 31 5f 74 78 5f 70 6b 74 00 6b 6b 6b 6b  ppe1_tx_pkt.kkkk
      [   43.115217] 030: 70 70 65 31 5f 74 78 5f 70 6b 74 5f 6f 6b 00 6b  ppe1_tx_pkt_ok.k
      [   43.115218] Next obj: start=ffff801fb0b69098, len=80
      [   43.115220] Redzone: 0x706d655f6f666966/0x9f911029d74e35b.
      [   43.115229] Last user: [<ffff0000084b11b0>](acpi_os_release_object+0x28/0x38)
      [   43.115231] 000: 74 79 00 6b 6b 6b 6b 6b 70 70 65 31 5f 74 78 5f  ty.kkkkkppe1_tx_
      [   43.115232] 010: 70 6b 74 5f 65 72 72 5f 63 73 75 6d 5f 66 61 69  pkt_err_csum_fai
      Signed-off-by: NTimmy Li <lixiaoping3@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      412b65d1
  15. 01 5月, 2017 2 次提交
  16. 04 4月, 2017 16 次提交
  17. 02 4月, 2017 1 次提交
  18. 29 3月, 2017 1 次提交
  19. 26 3月, 2017 2 次提交
    • A
      net: hns: avoid gcc-7.0.1 warning for uninitialized data · 834a61d4
      Arnd Bergmann 提交于
      hns_dsaf_set_mac_key() calls dsaf_set_field() on an uninitialized field,
      which will then change only a few of its bits, causing a warning with
      the latest gcc:
      
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_set_mac_uc_entry':
      hisilicon/hns/hns_dsaf_reg.h:1046:12: error: 'mac_key.low.bits.port_vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         (origin) &= (~(mask)); \
                  ^~
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_set_mac_mc_entry':
      hisilicon/hns/hns_dsaf_reg.h:1046:12: error: 'mac_key.low.bits.port_vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_add_mac_mc_port':
      hisilicon/hns/hns_dsaf_reg.h:1046:12: error: 'mac_key.low.bits.port_vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_del_mac_entry':
      hisilicon/hns/hns_dsaf_reg.h:1046:12: error: 'mac_key.low.bits.port_vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_rm_mac_addr':
      hisilicon/hns/hns_dsaf_reg.h:1046:12: error: 'mac_key.low.bits.port_vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_del_mac_mc_port':
      hisilicon/hns/hns_dsaf_reg.h:1046:12: error: 'mac_key.low.bits.port_vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_mac_uc_entry':
      hisilicon/hns/hns_dsaf_reg.h:1046:12: error: 'mac_key.low.bits.port_vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_mac_mc_entry':
      hisilicon/hns/hns_dsaf_reg.h:1046:12: error: 'mac_key.low.bits.port_vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      The code is actually correct since we always set all 16 bits of the
      port_vlan field, but gcc correctly points out that the first
      access does contain uninitialized data.
      
      This initializes the field to zero first before setting the
      individual bits.
      
      Fixes: 5483bfcb ("net: hns: modify tcam table and set mac key")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      834a61d4
    • A
      net: hns: fix uninitialized data use · a17f1861
      Arnd Bergmann 提交于
      When dev_dbg() is enabled, we print uninitialized data, as gcc-7.0.1
      now points out:
      
      ethernet/hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_set_promisc_tcam':
      ethernet/hisilicon/hns/hns_dsaf_main.c:2947:75: error: 'tbl_tcam_data.low.val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      ethernet/hisilicon/hns/hns_dsaf_main.c:2947:75: error: 'tbl_tcam_data.high.val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      We also pass the data into hns_dsaf_tcam_mc_cfg(), which might later
      use it (not sure about that), so it seems safer to just always initialize
      the tbl_tcam_data structure.
      
      Fixes: 1f5fa2dd ("net: hns: fix for promisc mode in HNS driver")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a17f1861
  20. 11 2月, 2017 1 次提交
  21. 07 2月, 2017 1 次提交
    • A
      hns: avoid stack overflow with CONFIG_KASAN · b3f2d07f
      Arnd Bergmann 提交于
      The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use
      an indexed load for the register address, but it has an absolutely detrimental
      effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely
      kernel stack overflow aside from very complex object code:
      
      hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats':
      hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common':
      hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs':
      hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs':
      hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs':
      hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs':
      hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init':
      hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs':
      hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats':
      hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs':
      hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE
      seems safe anyway and it avoids a serious issue for some people. I have verified
      that with gcc-5.3.1, the object code we get is better in the new version
      both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte
      stack frame for hns_dsaf_get_regs() but otherwise have practically identical
      object code.
      
      With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already
      good either way.
      
      This patch is probably not urgent to get into 4.11 as only KASAN=y builds
      with certain compilers are affected, but I still think it makes sense to
      backport into older kernels.
      
      Cc: stable@vger.kernel.org
      Fixes: 511e6bc0 ("net: add Hisilicon Network Subsystem DSAF support")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3f2d07f
  22. 04 2月, 2017 1 次提交
    • A
      hns_enet: use cpumask_var_t for on-stack mask · ff3edc9b
      Arnd Bergmann 提交于
      On large SMP builds, we can run into a build warning:
      
      drivers/net/ethernet/hisilicon/hns/hns_enet.c: In function 'hns_set_irq_affinity.isra.27':
      drivers/net/ethernet/hisilicon/hns/hns_enet.c:1242:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      The solution here is to use cpumask_var_t, which can use dynamic
      allocation when CONFIG_CPUMASK_OFFSTACK is enabled.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff3edc9b
  23. 19 1月, 2017 1 次提交
    • T
      net: Remove usage of net_device last_rx member · 4a7c9726
      Tobias Klauser 提交于
      The network stack no longer uses the last_rx member of struct net_device
      since the bonding driver switched to use its own private last_rx in
      commit 9f242738 ("bonding: use last_arp_rx in slave_last_rx()").
      
      However, some drivers still (ab)use the field for their own purposes and
      some driver just update it without actually using it.
      
      Previously, there was an accompanying comment for the last_rx member
      added in commit 4dc89133 ("net: add a comment on netdev->last_rx")
      which asked drivers not to update is, unless really needed. However,
      this commend was removed in commit f8ff080d ("bonding: remove
      useless updating of slave->dev->last_rx"), so some drivers added later
      on still did update last_rx.
      
      Remove all usage of last_rx and switch three drivers (sky2, atp and
      smc91c92_cs) which actually read and write it to use their own private
      copy in netdev_priv.
      
      Compile-tested with allyesconfig and allmodconfig on x86 and arm.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a7c9726