1. 09 5月, 2018 1 次提交
  2. 26 4月, 2018 1 次提交
  3. 25 4月, 2018 4 次提交
  4. 19 4月, 2018 1 次提交
  5. 12 4月, 2018 2 次提交
  6. 09 4月, 2018 2 次提交
    • R
      HID: hidraw: Fix crash on HIDIOCGFEATURE with a destroyed device · a955358d
      Rodrigo Rivas Costa 提交于
      Doing `ioctl(HIDIOCGFEATURE)` in a tight loop on a hidraw device
      and then disconnecting the device, or unloading the driver, can
      cause a NULL pointer dereference.
      
      When a hidraw device is destroyed it sets 0 to `dev->exist`.
      Most functions check 'dev->exist' before doing its work, but
      `hidraw_get_report()` was missing that check.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NRodrigo Rivas Costa <rodrigorivascosta@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      a955358d
    • D
      HID: input: fix battery level reporting on BT mice · 2e210bbb
      Dmitry Torokhov 提交于
      The commit 581c4484 ("HID: input: map digitizer battery usage")
      assumed that devices having input (qas opposed to feature) report for
      battery strength would report the data on their own, without the need to
      be polled by the kernel; unfortunately it is not so. Many wireless mice
      do not send unsolicited reports with battery strength data and have to
      be polled explicitly. As a complication, stylus devices on digitizers
      are not normally connected to the base and thus can not be polled - the
      base can only determine battery strength in the stylus when it is in
      proximity.
      
      To solve this issue, we add a special flag that tells the kernel
      to avoid polling the device (and expect unsolicited reports) and set it
      when report field with physical usage of digitizer stylus (HID_DG_STYLUS).
      Unless this flag is set, and we have not seen the unsolicited reports,
      the kernel will attempt to poll the device when userspace attempts to
      read "capacity" and "state" attributes of power_supply object
      corresponding to the devices battery.
      
      Fixes: 581c4484 ("HID: input: map digitizer battery usage")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NMartin van Es <martin@mrvanes.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      2e210bbb
  7. 05 4月, 2018 2 次提交
    • A
      netdevsim: remove incorrect __net_initdata annotations · 87248d31
      Arnd Bergmann 提交于
      The __net_initdata section cannot currently be used for structures that
      get cleaned up in an exitcall using unregister_pernet_operations:
      
      WARNING: vmlinux.o(.text+0x868c34): Section mismatch in reference from the function nsim_devlink_exit() to the (unknown reference) .init.data:(unknown)
      The function nsim_devlink_exit() references
      the (unknown reference) __initdata (unknown).
      This is often because nsim_devlink_exit lacks a __initdata
      annotation or the annotation of (unknown) is wrong.
      WARNING: vmlinux.o(.text+0x868c64): Section mismatch in reference from the function nsim_devlink_init() to the (unknown reference) .init.data:(unknown)
      WARNING: vmlinux.o(.text+0x8692bc): Section mismatch in reference from the function nsim_fib_exit() to the (unknown reference) .init.data:(unknown)
      WARNING: vmlinux.o(.text+0x869300): Section mismatch in reference from the function nsim_fib_init() to the (unknown reference) .init.data:(unknown)
      
      As that warning tells us, discarding the structure after a module is
      loaded would lead to a undefined behavior when that module is removed.
      
      It might be possible to change that annotation so it has no effect for
      loadable modules, but I have not figured out exactly how to do that, and
      we want this to be fixed in -rc1.
      
      This just removes the annotations, just like we do for all other such
      modules.
      
      Fixes: 37923ed6 ("netdevsim: Add simple FIB resource controller via devlink")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87248d31
    • B
      sfc: remove ctpio_dmabuf_start from stats · 458bd99e
      Bert Kenward 提交于
      The ctpio_dmabuf_start entry is not actually a stat and shouldn't
      be exposed to ethtool.
      
      Fixes: 2c0b6ee8 ("sfc: expose CTPIO stats on NICs that support them")
      Signed-off-by: NBert Kenward <bkenward@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      458bd99e
  8. 04 4月, 2018 11 次提交
    • A
      nvmem: disallow modular CONFIG_NVMEM · 2a37ce25
      Arnd Bergmann 提交于
      The new of_get_nvmem_mac_address() helper function causes a link error
      with CONFIG_NVMEM=m:
      
      drivers/of/of_net.o: In function `of_get_nvmem_mac_address':
      of_net.c:(.text+0x168): undefined reference to `of_nvmem_cell_get'
      of_net.c:(.text+0x19c): undefined reference to `nvmem_cell_read'
      of_net.c:(.text+0x1a8): undefined reference to `nvmem_cell_put'
      
      I could not come up with a good solution for this, as the code is always
      built-in. Using an #if IS_REACHABLE() check around it would solve the
      link time issue but then stop it from working in that configuration.
      Making of_nvmem_cell_get() an inline function could also solve that, but
      seems a bit ugly since it's somewhat larger than most inline functions,
      and it would just bring that problem into the callers.  Splitting the
      function into a separate file might be an alternative.
      
      This uses the big hammer by making CONFIG_NVMEM itself a 'bool' symbol,
      which avoids the problem entirely but makes the vmlinux larger for anyone
      that might use NVMEM support but doesn't need it built-in otherwise.
      
      Fixes: 9217e566 ("of_net: Implement of_get_nvmem_mac_address helper")
      Cc: Mike Looijmans <mike.looijmans@topic.nl>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: Mike Looijmans
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a37ce25
    • T
      net: hns3: fix length overflow when CONFIG_ARM64_64K_PAGES · 48d154e7
      Tan Xiaojun 提交于
      When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE
      is 65536(64K). But the type of length is u16, it will overflow. So change it
      to u32.
      Signed-off-by: NTan Xiaojun <tanxiaojun@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48d154e7
    • D
      nfp: use full 40 bits of the NSP buffer address · 1489bbd1
      Dirk van der Merwe 提交于
      The NSP default buffer is a piece of NFP memory where additional
      command data can be placed.  Its format has been copied from
      host buffer, but the PCIe selection bits do not make sense in
      this case.  If those get masked out from a NFP address - writes
      to random place in the chip memory may be issued and crash the
      device.
      
      Even in the general NSP buffer case, it doesn't make sense to have the
      PCIe selection bits there anymore. These are unused at the moment, and
      when it becomes necessary, the PCIe selection bits should rather be
      moved to another register to utilise more bits for the buffer address.
      
      This has never been an issue because the buffer used to be
      allocated in memory with less-than-38-bit-long address but that
      is about to change.
      
      Fixes: 1a64821c ("nfp: add support for service processor access")
      Signed-off-by: NDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1489bbd1
    • A
      lan78xx: Connect phy early · 92571a1a
      Alexander Graf 提交于
      When using wicked with a lan78xx device attached to the system, we
      end up with ethtool commands issued on the device before an ifup
      got issued. That lead to the following crash:
      
          Unable to handle kernel NULL pointer dereference at virtual address 0000039c
          pgd = ffff800035b30000
          [0000039c] *pgd=0000000000000000
          Internal error: Oops: 96000004 [#1] SMP
          Modules linked in: [...]
          Supported: Yes
          CPU: 3 PID: 638 Comm: wickedd Tainted: G            E      4.12.14-0-default #1
          Hardware name: raspberrypi rpi/rpi, BIOS 2018.03-rc2 02/21/2018
          task: ffff800035e74180 task.stack: ffff800036718000
          PC is at phy_ethtool_ksettings_get+0x20/0x98
          LR is at lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
          pc : [<ffff0000086f7f30>] lr : [<ffff000000dcca84>] pstate: 20000005
          sp : ffff80003671bb20
          x29: ffff80003671bb20 x28: ffff800035e74180
          x27: ffff000008912000 x26: 000000000000001d
          x25: 0000000000000124 x24: ffff000008f74d00
          x23: 0000004000114809 x22: 0000000000000000
          x21: ffff80003671bbd0 x20: 0000000000000000
          x19: ffff80003671bbd0 x18: 000000000000040d
          x17: 0000000000000001 x16: 0000000000000000
          x15: 0000000000000000 x14: ffffffffffffffff
          x13: 0000000000000000 x12: 0000000000000020
          x11: 0101010101010101 x10: fefefefefefefeff
          x9 : 7f7f7f7f7f7f7f7f x8 : fefefeff31677364
          x7 : 0000000080808080 x6 : ffff80003671bc9c
          x5 : ffff80003671b9f8 x4 : ffff80002c296190
          x3 : 0000000000000000 x2 : 0000000000000000
          x1 : ffff80003671bbd0 x0 : ffff80003671bc00
          Process wickedd (pid: 638, stack limit = 0xffff800036718000)
          Call trace:
          Exception stack(0xffff80003671b9e0 to 0xffff80003671bb20)
          b9e0: ffff80003671bc00 ffff80003671bbd0 0000000000000000 0000000000000000
          ba00: ffff80002c296190 ffff80003671b9f8 ffff80003671bc9c 0000000080808080
          ba20: fefefeff31677364 7f7f7f7f7f7f7f7f fefefefefefefeff 0101010101010101
          ba40: 0000000000000020 0000000000000000 ffffffffffffffff 0000000000000000
          ba60: 0000000000000000 0000000000000001 000000000000040d ffff80003671bbd0
          ba80: 0000000000000000 ffff80003671bbd0 0000000000000000 0000004000114809
          baa0: ffff000008f74d00 0000000000000124 000000000000001d ffff000008912000
          bac0: ffff800035e74180 ffff80003671bb20 ffff000000dcca84 ffff80003671bb20
          bae0: ffff0000086f7f30 0000000020000005 ffff80002c296000 ffff800035223900
          bb00: 0000ffffffffffff 0000000000000000 ffff80003671bb20 ffff0000086f7f30
          [<ffff0000086f7f30>] phy_ethtool_ksettings_get+0x20/0x98
          [<ffff000000dcca84>] lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
          [<ffff0000087cbc40>] ethtool_get_settings+0x68/0x210
          [<ffff0000087cc0d4>] dev_ethtool+0x214/0x2180
          [<ffff0000087e5008>] dev_ioctl+0x400/0x630
          [<ffff00000879dd00>] sock_do_ioctl+0x70/0x88
          [<ffff00000879f5f8>] sock_ioctl+0x208/0x368
          [<ffff0000082cde10>] do_vfs_ioctl+0xb0/0x848
          [<ffff0000082ce634>] SyS_ioctl+0x8c/0xa8
          Exception stack(0xffff80003671bec0 to 0xffff80003671c000)
          bec0: 0000000000000009 0000000000008946 0000fffff4e841d0 0000aa0032687465
          bee0: 0000aaaafa2319d4 0000fffff4e841d4 0000000032687465 0000000032687465
          bf00: 000000000000001d 7f7fff7f7f7f7f7f 72606b622e71ff4c 7f7f7f7f7f7f7f7f
          bf20: 0101010101010101 0000000000000020 ffffffffffffffff 0000ffff7f510c68
          bf40: 0000ffff7f6a9d18 0000ffff7f44ce30 000000000000040d 0000ffff7f6f98f0
          bf60: 0000fffff4e842c0 0000000000000001 0000aaaafa2c2e00 0000ffff7f6ab000
          bf80: 0000fffff4e842c0 0000ffff7f62a000 0000aaaafa2b9f20 0000aaaafa2c2e00
          bfa0: 0000fffff4e84818 0000fffff4e841a0 0000ffff7f5ad0cc 0000fffff4e841a0
          bfc0: 0000ffff7f44ce3c 0000000080000000 0000000000000009 000000000000001d
          bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      
      The culprit is quite simple: The driver tries to access the phy left and right,
      but only actually has a working reference to it when the device is up.
      
      The fix thus is quite simple too: Get a reference to the phy on probe already
      and keep it even when the device is going down.
      
      With this patch applied, I can successfully run wicked on my system and bring
      the interface up and down as many times as I want, without getting NULL pointer
      dereferences in between.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92571a1a
    • J
      nfp: add a separate counter for packets with CHECKSUM_COMPLETE · 0df57e60
      Jakub Kicinski 提交于
      We are currently counting packets with CHECKSUM_COMPLETE as
      "hw_rx_csum_ok".  This is confusing.  Add a new counter.
      To make sure it fits in the same cacheline move the less used
      error counter to a different location.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0df57e60
    • R
      net: phy: marvell10g: add thermal hwmon device · 0d3ad854
      Russell King 提交于
      Add a thermal monitoring device for the Marvell 88x3310, which updates
      once a second.  We also need to hook into the suspend/resume mechanism
      to ensure that the thermal monitoring is reconfigured when we resume.
      Suggested-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d3ad854
    • E
      pptp: remove a buggy dst release in pptp_connect() · bfacfb45
      Eric Dumazet 提交于
      Once dst has been cached in socket via sk_setup_caps(),
      it is illegal to call ip_rt_put() (or dst_release()),
      since sk_setup_caps() did not change dst refcount.
      
      We can still dereference it since we hold socket lock.
      
      Caugth by syzbot :
      
      BUG: KASAN: use-after-free in atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline]
      BUG: KASAN: use-after-free in dst_release+0x27/0xa0 net/core/dst.c:185
      Write of size 4 at addr ffff8801c54dc040 by task syz-executor4/20088
      
      CPU: 1 PID: 20088 Comm: syz-executor4 Not tainted 4.16.0+ #376
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x1a7/0x27d lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report+0x23c/0x360 mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
       kasan_check_write+0x14/0x20 mm/kasan/kasan.c:278
       atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline]
       dst_release+0x27/0xa0 net/core/dst.c:185
       sk_dst_set include/net/sock.h:1812 [inline]
       sk_dst_reset include/net/sock.h:1824 [inline]
       sock_setbindtodevice net/core/sock.c:610 [inline]
       sock_setsockopt+0x431/0x1b20 net/core/sock.c:707
       SYSC_setsockopt net/socket.c:1845 [inline]
       SyS_setsockopt+0x2ff/0x360 net/socket.c:1828
       do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      RIP: 0033:0x4552d9
      RSP: 002b:00007f4878126c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
      RAX: ffffffffffffffda RBX: 00007f48781276d4 RCX: 00000000004552d9
      RDX: 0000000000000019 RSI: 0000000000000001 RDI: 0000000000000013
      RBP: 000000000072bea0 R08: 0000000000000010 R09: 0000000000000000
      R10: 00000000200010c0 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 0000000000000526 R14: 00000000006fac30 R15: 0000000000000000
      
      Allocated by task 20088:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
       kmem_cache_alloc+0x12e/0x760 mm/slab.c:3542
       dst_alloc+0x11f/0x1a0 net/core/dst.c:104
       rt_dst_alloc+0xe9/0x540 net/ipv4/route.c:1520
       __mkroute_output net/ipv4/route.c:2265 [inline]
       ip_route_output_key_hash_rcu+0xa49/0x2c60 net/ipv4/route.c:2493
       ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2322
       __ip_route_output_key include/net/route.h:126 [inline]
       ip_route_output_flow+0x26/0xa0 net/ipv4/route.c:2577
       ip_route_output_ports include/net/route.h:163 [inline]
       pptp_connect+0xa84/0x1170 drivers/net/ppp/pptp.c:453
       SYSC_connect+0x213/0x4a0 net/socket.c:1639
       SyS_connect+0x24/0x30 net/socket.c:1620
       do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      Freed by task 20082:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
       kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
       __cache_free mm/slab.c:3486 [inline]
       kmem_cache_free+0x83/0x2a0 mm/slab.c:3744
       dst_destroy+0x266/0x380 net/core/dst.c:140
       dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
       __rcu_reclaim kernel/rcu/rcu.h:178 [inline]
       rcu_do_batch kernel/rcu/tree.c:2675 [inline]
       invoke_rcu_callbacks kernel/rcu/tree.c:2930 [inline]
       __rcu_process_callbacks kernel/rcu/tree.c:2897 [inline]
       rcu_process_callbacks+0xd6c/0x17b0 kernel/rcu/tree.c:2914
       __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
      
      The buggy address belongs to the object at ffff8801c54dc000
       which belongs to the cache ip_dst_cache of size 168
      The buggy address is located 64 bytes inside of
       168-byte region [ffff8801c54dc000, ffff8801c54dc0a8)
      The buggy address belongs to the page:
      page:ffffea0007153700 count:1 mapcount:0 mapping:ffff8801c54dc000 index:0x0
      flags: 0x2fffc0000000100(slab)
      raw: 02fffc0000000100 ffff8801c54dc000 0000000000000000 0000000100000010
      raw: ffffea0006b34b20 ffffea0006b6c1e0 ffff8801d674a1c0 0000000000000000
      page dumped because: kasan: bad access detected
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bfacfb45
    • F
      net: dsa: mt7530: Use NULL instead of plain integer · 18bd5949
      Florian Fainelli 提交于
      We would be passing 0 instead of NULL as the rsp argument to
      mt7530_fdb_cmd(), fix that.
      
      Fixes: b8f126a8 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NSean Wang <sean.wang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18bd5949
    • F
      net: dsa: b53: Fix sparse warnings in b53_mmap.c · 861690d0
      Florian Fainelli 提交于
      sparse complains about the following warnings:
      
      drivers/net/dsa/b53/b53_mmap.c:33:31: warning: incorrect type in
      initializer (different address spaces)
      drivers/net/dsa/b53/b53_mmap.c:33:31:    expected unsigned char
      [noderef] [usertype] <asn:2>*regs
      drivers/net/dsa/b53/b53_mmap.c:33:31:    got void *priv
      
      and indeed, while what we are doing is functional, we are dereferencing
      a void * pointer into a void __iomem * which is not great. Just use the
      defined b53_mmap_priv structure which holds our register base and use
      that.
      
      Fixes: 967dd82f ("net: dsa: b53: Add support for Broadcom RoboSwitch")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      861690d0
    • F
      net: systemport: Fix sparse warnings in bcm_sysport_insert_tsb() · c0eb0558
      Florian Fainelli 提交于
      skb->protocol is a __be16 which we would be calling htons() against,
      while this is not wrong per-se as it correctly results in swapping the
      value on LE hosts, this still upsets sparse. Adopt a similar pattern to
      what other drivers do and just assign ip_ver to skb->protocol, and then
      use htons() against the different constants such that the compiler can
      resolve the values at build time.
      
      Fixes: 80105bef ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0eb0558
    • F
      net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum() · 6f894211
      Florian Fainelli 提交于
      skb->protocol is a __be16 which we would be calling htons() against,
      while this is not wrong per-se as it correctly results in swapping the
      value on LE hosts, this still upsets sparse. Adopt a similar pattern to
      what other drivers do and just assign ip_ver to skb->protocol, and then
      use htons() against the different constants such that the compiler can
      resolve the values at build time.
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f894211
  9. 03 4月, 2018 6 次提交
  10. 02 4月, 2018 10 次提交