1. 09 1月, 2020 8 次提交
    • R
      HID: steam: Fix input device disappearing · 20eee6e5
      Rodrigo Rivas Costa 提交于
      The `connected` value for wired devices was not properly initialized,
      it must be set to `true` upon creation, because wired devices do not
      generate connection events.
      
      When a raw client (the Steam Client) uses the device, the input device
      is destroyed. Then, when the raw client finishes, it must be recreated.
      But since the `connected` variable was false this never happended.
      Signed-off-by: NRodrigo Rivas Costa <rodrigorivascosta@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      20eee6e5
    • A
      atm: eni: fix uninitialized variable warning · 30780d08
      Arnd Bergmann 提交于
      With -O3, gcc has found an actual unintialized variable stored
      into an mmio register in two instances:
      
      drivers/atm/eni.c: In function 'discard':
      drivers/atm/eni.c:465:13: error: 'dma[1]' is used uninitialized in this function [-Werror=uninitialized]
         writel(dma[i*2+1],eni_dev->rx_dma+dma_wr*8+4);
                   ^
      drivers/atm/eni.c:465:13: error: 'dma[3]' is used uninitialized in this function [-Werror=uninitialized]
      
      Change the code to always write zeroes instead.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30780d08
    • E
      macvlan: do not assume mac_header is set in macvlan_broadcast() · 96cc4b69
      Eric Dumazet 提交于
      Use of eth_hdr() in tx path is error prone.
      
      Many drivers call skb_reset_mac_header() before using it,
      but others do not.
      
      Commit 6d1ccff6 ("net: reset mac header in dev_start_xmit()")
      attempted to fix this generically, but commit d346a3fa
      ("packet: introduce PACKET_QDISC_BYPASS socket option") brought
      back the macvlan bug.
      
      Lets add a new helper, so that tx paths no longer have
      to call skb_reset_mac_header() only to get a pointer
      to skb->data.
      
      Hopefully we will be able to revert 6d1ccff6
      ("net: reset mac header in dev_start_xmit()") and save few cycles
      in transmit fast path.
      
      BUG: KASAN: use-after-free in __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline]
      BUG: KASAN: use-after-free in mc_hash drivers/net/macvlan.c:251 [inline]
      BUG: KASAN: use-after-free in macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277
      Read of size 4 at addr ffff8880a4932401 by task syz-executor947/9579
      
      CPU: 0 PID: 9579 Comm: syz-executor947 Not tainted 5.5.0-rc4-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x197/0x210 lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
       __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
       kasan_report+0x12/0x20 mm/kasan/common.c:639
       __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:145
       __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline]
       mc_hash drivers/net/macvlan.c:251 [inline]
       macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277
       macvlan_queue_xmit drivers/net/macvlan.c:520 [inline]
       macvlan_start_xmit+0x402/0x77f drivers/net/macvlan.c:559
       __netdev_start_xmit include/linux/netdevice.h:4447 [inline]
       netdev_start_xmit include/linux/netdevice.h:4461 [inline]
       dev_direct_xmit+0x419/0x630 net/core/dev.c:4079
       packet_direct_xmit+0x1a9/0x250 net/packet/af_packet.c:240
       packet_snd net/packet/af_packet.c:2966 [inline]
       packet_sendmsg+0x260d/0x6220 net/packet/af_packet.c:2991
       sock_sendmsg_nosec net/socket.c:639 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:659
       __sys_sendto+0x262/0x380 net/socket.c:1985
       __do_sys_sendto net/socket.c:1997 [inline]
       __se_sys_sendto net/socket.c:1993 [inline]
       __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1993
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x442639
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffc13549e08 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000442639
      RDX: 000000000000000e RSI: 0000000020000080 RDI: 0000000000000003
      RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 0000000000403bb0 R14: 0000000000000000 R15: 0000000000000000
      
      Allocated by task 9389:
       save_stack+0x23/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       __kasan_kmalloc mm/kasan/common.c:513 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527
       __do_kmalloc mm/slab.c:3656 [inline]
       __kmalloc+0x163/0x770 mm/slab.c:3665
       kmalloc include/linux/slab.h:561 [inline]
       tomoyo_realpath_from_path+0xc5/0x660 security/tomoyo/realpath.c:252
       tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
       tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822
       tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129
       security_inode_getattr+0xf2/0x150 security/security.c:1222
       vfs_getattr+0x25/0x70 fs/stat.c:115
       vfs_statx_fd+0x71/0xc0 fs/stat.c:145
       vfs_fstat include/linux/fs.h:3265 [inline]
       __do_sys_newfstat+0x9b/0x120 fs/stat.c:378
       __se_sys_newfstat fs/stat.c:375 [inline]
       __x64_sys_newfstat+0x54/0x80 fs/stat.c:375
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 9389:
       save_stack+0x23/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       kasan_set_free_info mm/kasan/common.c:335 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:483
       __cache_free mm/slab.c:3426 [inline]
       kfree+0x10a/0x2c0 mm/slab.c:3757
       tomoyo_realpath_from_path+0x1a7/0x660 security/tomoyo/realpath.c:289
       tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
       tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822
       tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129
       security_inode_getattr+0xf2/0x150 security/security.c:1222
       vfs_getattr+0x25/0x70 fs/stat.c:115
       vfs_statx_fd+0x71/0xc0 fs/stat.c:145
       vfs_fstat include/linux/fs.h:3265 [inline]
       __do_sys_newfstat+0x9b/0x120 fs/stat.c:378
       __se_sys_newfstat fs/stat.c:375 [inline]
       __x64_sys_newfstat+0x54/0x80 fs/stat.c:375
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8880a4932000
       which belongs to the cache kmalloc-4k of size 4096
      The buggy address is located 1025 bytes inside of
       4096-byte region [ffff8880a4932000, ffff8880a4933000)
      The buggy address belongs to the page:
      page:ffffea0002924c80 refcount:1 mapcount:0 mapping:ffff8880aa402000 index:0x0 compound_mapcount: 0
      raw: 00fffe0000010200 ffffea0002846208 ffffea00028f3888 ffff8880aa402000
      raw: 0000000000000000 ffff8880a4932000 0000000100000001 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880a4932300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880a4932380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8880a4932400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                         ^
       ffff8880a4932480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880a4932500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: b863ceb7 ("[NET]: Add macvlan driver")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96cc4b69
    • P
      mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO · 3971a535
      Petr Machata 提交于
      The following patch will change PRIO to replace a removed Qdisc with an
      invisible FIFO, instead of NOOP. mlxsw will see this replacement due to the
      graft message that is generated. But because FIFO does not issue its own
      REPLACE message, when the graft operation takes place, the Qdisc that mlxsw
      tracks under the indicated band is still the old one. The child
      handle (0:0) therefore does not match, and mlxsw rejects the graft
      operation, which leads to an extack message:
      
          Warning: Offloading graft operation failed.
      
      Fix by ignoring the invisible children in the PRIO graft handler. The
      DESTROY message of the removed Qdisc is going to follow shortly and handle
      the removal.
      
      Fixes: 32dc5efc ("mlxsw: spectrum: qdiscs: prio: Handle graft command")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3971a535
    • E
      gtp: fix bad unlock balance in gtp_encap_enable_socket · 90d72256
      Eric Dumazet 提交于
      WARNING: bad unlock balance detected!
      5.5.0-rc5-syzkaller #0 Not tainted
      -------------------------------------
      syz-executor921/9688 is trying to release lock (sk_lock-AF_INET6) at:
      [<ffffffff84bf8506>] gtp_encap_enable_socket+0x146/0x400 drivers/net/gtp.c:830
      but there are no more locks to release!
      
      other info that might help us debug this:
      2 locks held by syz-executor921/9688:
       #0: ffffffff8a4d8840 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:72 [inline]
       #0: ffffffff8a4d8840 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x405/0xaf0 net/core/rtnetlink.c:5421
       #1: ffff88809304b560 (slock-AF_INET6){+...}, at: spin_lock_bh include/linux/spinlock.h:343 [inline]
       #1: ffff88809304b560 (slock-AF_INET6){+...}, at: release_sock+0x20/0x1c0 net/core/sock.c:2951
      
      stack backtrace:
      CPU: 0 PID: 9688 Comm: syz-executor921 Not tainted 5.5.0-rc5-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x197/0x210 lib/dump_stack.c:118
       print_unlock_imbalance_bug kernel/locking/lockdep.c:4008 [inline]
       print_unlock_imbalance_bug.cold+0x114/0x123 kernel/locking/lockdep.c:3984
       __lock_release kernel/locking/lockdep.c:4242 [inline]
       lock_release+0x5f2/0x960 kernel/locking/lockdep.c:4503
       sock_release_ownership include/net/sock.h:1496 [inline]
       release_sock+0x17c/0x1c0 net/core/sock.c:2961
       gtp_encap_enable_socket+0x146/0x400 drivers/net/gtp.c:830
       gtp_encap_enable drivers/net/gtp.c:852 [inline]
       gtp_newlink+0x9fc/0xc60 drivers/net/gtp.c:666
       __rtnl_newlink+0x109e/0x1790 net/core/rtnetlink.c:3305
       rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3363
       rtnetlink_rcv_msg+0x45e/0xaf0 net/core/rtnetlink.c:5424
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x58c/0x7d0 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:639 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:659
       ____sys_sendmsg+0x753/0x880 net/socket.c:2330
       ___sys_sendmsg+0x100/0x170 net/socket.c:2384
       __sys_sendmsg+0x105/0x1d0 net/socket.c:2417
       __do_sys_sendmsg net/socket.c:2426 [inline]
       __se_sys_sendmsg net/socket.c:2424 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2424
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x445d49
      Code: e8 bc b7 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f8019074db8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000006dac38 RCX: 0000000000445d49
      RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
      RBP: 00000000006dac30 R08: 0000000000000004 R09: 0000000000000000
      R10: 0000000000000008 R11: 0000000000000246 R12: 00000000006dac3c
      R13: 00007ffea687f6bf R14: 00007f80190759c0 R15: 20c49ba5e353f7cf
      
      Fixes: e198987e ("gtp: fix suspicious RCU usage")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Taehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90d72256
    • C
      net: stmmac: dwmac-sun8i: Allow all RGMII modes · f1239d8a
      Chen-Yu Tsai 提交于
      Allow all the RGMII modes to be used. This would allow us to represent
      the hardware better in the device tree with RGMII_ID where in most
      cases the PHY's internal delay for both RX and TX are used.
      
      Fixes: 9f93ac8d ("net-next: stmmac: Add dwmac-sun8i")
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1239d8a
    • C
      net: stmmac: dwmac-sunxi: Allow all RGMII modes · 52cc73e5
      Chen-Yu Tsai 提交于
      Allow all the RGMII modes to be used. This would allow us to represent
      the hardware better in the device tree with RGMII_ID where in most
      cases the PHY's internal delay for both RX and TX are used.
      
      Fixes: af0bd4e9 ("net: stmmac: sunxi platform extensions for GMAC in Allwinner A20 SoC's")
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52cc73e5
    • T
      tpm: Handle negative priv->response_len in tpm_common_read() · a430e67d
      Tadeusz Struk 提交于
      The priv->response_length can hold the size of an response or an negative
      error code, and the tpm_common_read() needs to handle both cases correctly.
      Changed the type of response_length to signed and accounted for negative
      value in tpm_common_read().
      
      Cc: stable@vger.kernel.org
      Fixes: d23d1248 ("tpm: fix invalid locking in NONBLOCKING mode")
      Reported-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com>
      Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      a430e67d
  2. 08 1月, 2020 7 次提交
  3. 07 1月, 2020 25 次提交