1. 17 Dec, 2018 11 commits
    • Adam Ford's avatar
      ARM: dts: logicpd-somlv: Fix interrupt on mmc3_dat1 · 2e6ef7e3
      Adam Ford authored
      [ Upstream commit 3d8b804bc528d3720ec0c39c212af92dafaf6e84 ]
      
      The interrupt on mmc3_dat1 is wrong which prevents this from
      appearing in /proc/interrupts.
      
      Fixes: ab8dd3ae ("ARM: DTS: Add minimal Support for Logic PD
      DM3730 SOM-LV") #Kernel 4.9+
      Signed-off-by: default avatarAdam Ford <aford173@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2e6ef7e3
    • Nathan Chancellor's avatar
      ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup · e6b4f360
      Nathan Chancellor authored
      [ Upstream commit eef3dc34a1e0b01d53328b88c25237bcc7323777 ]
      
      When building the kernel with Clang, the following section mismatch
      warning appears:
      
      WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from
      the function omap44xx_prm_late_init() to the function
      .init.text:omap44xx_prm_enable_io_wakeup()
      The function omap44xx_prm_late_init() references
      the function __init omap44xx_prm_enable_io_wakeup().
      This is often because omap44xx_prm_late_init lacks a __init
      annotation or the annotation of omap44xx_prm_enable_io_wakeup is wrong.
      
      Remove the __init annotation from omap44xx_prm_enable_io_wakeup so there
      is no more mismatch.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e6b4f360
    • Stefano Brivio's avatar
      neighbour: Avoid writing before skb->head in neigh_hh_output() · 5873b2c7
      Stefano Brivio authored
      [ Upstream commit e6ac64d4c4d095085d7dd71cbd05704ac99829b2 ]
      
      While skb_push() makes the kernel panic if the skb headroom is less than
      the unaligned hardware header size, it will proceed normally in case we
      copy more than that because of alignment, and we'll silently corrupt
      adjacent slabs.
      
      In the case fixed by the previous patch,
      "ipv6: Check available headroom in ip6_xmit() even without options", we
      end up in neigh_hh_output() with 14 bytes headroom, 14 bytes hardware
      header and write 16 bytes, starting 2 bytes before the allocated buffer.
      
      Always check we're not writing before skb->head and, if the headroom is
      not enough, warn and drop the packet.
      
      v2:
       - instead of panicking with BUG_ON(), WARN_ON_ONCE() and drop the packet
         (Eric Dumazet)
       - if we avoid the panic, though, we need to explicitly check the headroom
         before the memcpy(), otherwise we'll have corrupted slabs on a running
         kernel, after we warn
       - use __skb_push() instead of skb_push(), as the headroom check is
         already implemented here explicitly (Eric Dumazet)
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5873b2c7
    • Nicolas Dichtel's avatar
      tun: forbid iface creation with rtnl ops · b28c2c74
      Nicolas Dichtel authored
      [ Upstream commit 35b827b6d06199841a83839e8bb69c0cd13a28be ]
      
      It's not supported right now (the goal of the initial patch was to support
      'ip link del' only).
      
      Before the patch:
      $ ip link add foo type tun
      [  239.632660] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      [snip]
      [  239.636410] RIP: 0010:register_netdevice+0x8e/0x3a0
      
      This panic occurs because dev->netdev_ops is not set by tun_setup(). But to
      have something usable, it will require more than just setting
      netdev_ops.
      
      Fixes: f019a7a5 ("tun: Implement ip link del tunXXX")
      CC: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b28c2c74
    • Yuchung Cheng's avatar
      tcp: fix NULL ref in tail loss probe · bd3fa7e1
      Yuchung Cheng authored
      [ Upstream commit b2b7af861122a0c0f6260155c29a1b2e594cd5b5 ]
      
      TCP loss probe timer may fire when the retranmission queue is empty but
      has a non-zero tp->packets_out counter. tcp_send_loss_probe will call
      tcp_rearm_rto which triggers NULL pointer reference by fetching the
      retranmission queue head in its sub-routines.
      
      Add a more detailed warning to help catch the root cause of the inflight
      accounting inconsistency.
      Reported-by: default avatarRafael Tinoco <rafael.tinoco@linaro.org>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd3fa7e1
    • Eric Dumazet's avatar
      rtnetlink: ndo_dflt_fdb_dump() only work for ARPHRD_ETHER devices · fe25279d
      Eric Dumazet authored
      [ Upstream commit 688838934c231bb08f46db687e57f6d8bf82709c ]
      
      kmsan was able to trigger a kernel-infoleak using a gre device [1]
      
      nlmsg_populate_fdb_fill() has a hard coded assumption
      that dev->addr_len is ETH_ALEN, as normally guaranteed
      for ARPHRD_ETHER devices.
      
      A similar issue was fixed recently in commit da71577545a5
      ("rtnetlink: Disallow FDB configuration for non-Ethernet device")
      
      [1]
      BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:143 [inline]
      BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576
      CPU: 0 PID: 6697 Comm: syz-executor310 Not tainted 4.20.0-rc3+ #95
      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+0x32d/0x480 lib/dump_stack.c:113
       kmsan_report+0x12c/0x290 mm/kmsan/kmsan.c:683
       kmsan_internal_check_memory+0x32a/0xa50 mm/kmsan/kmsan.c:743
       kmsan_copy_to_user+0x78/0xd0 mm/kmsan/kmsan_hooks.c:634
       copyout lib/iov_iter.c:143 [inline]
       _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576
       copy_to_iter include/linux/uio.h:143 [inline]
       skb_copy_datagram_iter+0x4e2/0x1070 net/core/datagram.c:431
       skb_copy_datagram_msg include/linux/skbuff.h:3316 [inline]
       netlink_recvmsg+0x6f9/0x19d0 net/netlink/af_netlink.c:1975
       sock_recvmsg_nosec net/socket.c:794 [inline]
       sock_recvmsg+0x1d1/0x230 net/socket.c:801
       ___sys_recvmsg+0x444/0xae0 net/socket.c:2278
       __sys_recvmsg net/socket.c:2327 [inline]
       __do_sys_recvmsg net/socket.c:2337 [inline]
       __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
       __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x441119
      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 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fffc7f008a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002f
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441119
      RDX: 0000000000000040 RSI: 00000000200005c0 RDI: 0000000000000003
      RBP: 00000000006cc018 R08: 0000000000000100 R09: 0000000000000100
      R10: 0000000000000100 R11: 0000000000000207 R12: 0000000000402080
      R13: 0000000000402110 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:261 [inline]
       kmsan_internal_chain_origin+0x13d/0x240 mm/kmsan/kmsan.c:469
       kmsan_memcpy_memmove_metadata+0x1a9/0xf70 mm/kmsan/kmsan.c:344
       kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:362
       __msan_memcpy+0x61/0x70 mm/kmsan/kmsan_instr.c:162
       __nla_put lib/nlattr.c:744 [inline]
       nla_put+0x20a/0x2d0 lib/nlattr.c:802
       nlmsg_populate_fdb_fill+0x444/0x810 net/core/rtnetlink.c:3466
       nlmsg_populate_fdb net/core/rtnetlink.c:3775 [inline]
       ndo_dflt_fdb_dump+0x73a/0x960 net/core/rtnetlink.c:3807
       rtnl_fdb_dump+0x1318/0x1cb0 net/core/rtnetlink.c:3979
       netlink_dump+0xc79/0x1c90 net/netlink/af_netlink.c:2244
       __netlink_dump_start+0x10c4/0x11d0 net/netlink/af_netlink.c:2352
       netlink_dump_start include/linux/netlink.h:216 [inline]
       rtnetlink_rcv_msg+0x141b/0x1540 net/core/rtnetlink.c:4910
       netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116
       __sys_sendmsg net/socket.c:2154 [inline]
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
       kmsan_internal_poison_shadow+0x6d/0x130 mm/kmsan/kmsan.c:170
       kmsan_kmalloc+0xa1/0x100 mm/kmsan/kmsan_hooks.c:186
       __kmalloc+0x14c/0x4d0 mm/slub.c:3825
       kmalloc include/linux/slab.h:551 [inline]
       __hw_addr_create_ex net/core/dev_addr_lists.c:34 [inline]
       __hw_addr_add_ex net/core/dev_addr_lists.c:80 [inline]
       __dev_mc_add+0x357/0x8a0 net/core/dev_addr_lists.c:670
       dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
       ip_mc_filter_add net/ipv4/igmp.c:1128 [inline]
       igmp_group_added+0x4d4/0xb80 net/ipv4/igmp.c:1311
       __ip_mc_inc_group+0xea9/0xf70 net/ipv4/igmp.c:1444
       ip_mc_inc_group net/ipv4/igmp.c:1453 [inline]
       ip_mc_up+0x1c3/0x400 net/ipv4/igmp.c:1775
       inetdev_event+0x1d03/0x1d80 net/ipv4/devinet.c:1522
       notifier_call_chain kernel/notifier.c:93 [inline]
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x13d/0x240 kernel/notifier.c:401
       __dev_notify_flags+0x3da/0x860 net/core/dev.c:1733
       dev_change_flags+0x1ac/0x230 net/core/dev.c:7569
       do_setlink+0x165f/0x5ea0 net/core/rtnetlink.c:2492
       rtnl_newlink+0x2ad7/0x35a0 net/core/rtnetlink.c:3111
       rtnetlink_rcv_msg+0x1148/0x1540 net/core/rtnetlink.c:4947
       netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116
       __sys_sendmsg net/socket.c:2154 [inline]
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Bytes 36-37 of 105 are uninitialized
      Memory access of size 105 starts at ffff88819686c000
      Data copied to user address 0000000020000380
      
      Fixes: d83b0603 ("net: add fdb generic dump routine")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe25279d
    • Christoph Paasch's avatar
      net: Prevent invalid access to skb->prev in __qdisc_drop_all · 8dd57cc3
      Christoph Paasch authored
      [ Upstream commit 9410d386d0a829ace9558336263086c2fbbe8aed ]
      
      __qdisc_drop_all() accesses skb->prev to get to the tail of the
      segment-list.
      
      With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
      the skb-list handling has been changed to set skb->next to NULL and set
      the list-poison on skb->prev.
      
      With that change, __qdisc_drop_all() will panic when it tries to
      dereference skb->prev.
      
      Since commit 992cba7e276d ("net: Add and use skb_list_del_init().")
      __list_del_entry is used, leaving skb->prev unchanged (thus,
      pointing to the list-head if it's the first skb of the list).
      This will make __qdisc_drop_all modify the next-pointer of the list-head
      and result in a panic later on:
      
      [   34.501053] general protection fault: 0000 [#1] SMP KASAN PTI
      [   34.501968] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.20.0-rc2.mptcp #108
      [   34.502887] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
      [   34.504074] RIP: 0010:dev_gro_receive+0x343/0x1f90
      [   34.504751] Code: e0 48 c1 e8 03 42 80 3c 30 00 0f 85 4a 1c 00 00 4d 8b 24 24 4c 39 65 d0 0f 84 0a 04 00 00 49 8d 7c 24 38 48 89 f8 48 c1 e8 03 <42> 0f b6 04 30 84 c0 74 08 3c 04
      [   34.507060] RSP: 0018:ffff8883af507930 EFLAGS: 00010202
      [   34.507761] RAX: 0000000000000007 RBX: ffff8883970b2c80 RCX: 1ffff11072e165a6
      [   34.508640] RDX: 1ffff11075867008 RSI: ffff8883ac338040 RDI: 0000000000000038
      [   34.509493] RBP: ffff8883af5079d0 R08: ffff8883970b2d40 R09: 0000000000000062
      [   34.510346] R10: 0000000000000034 R11: 0000000000000000 R12: 0000000000000000
      [   34.511215] R13: 0000000000000000 R14: dffffc0000000000 R15: ffff8883ac338008
      [   34.512082] FS:  0000000000000000(0000) GS:ffff8883af500000(0000) knlGS:0000000000000000
      [   34.513036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   34.513741] CR2: 000055ccc3e9d020 CR3: 00000003abf32000 CR4: 00000000000006e0
      [   34.514593] Call Trace:
      [   34.514893]  <IRQ>
      [   34.515157]  napi_gro_receive+0x93/0x150
      [   34.515632]  receive_buf+0x893/0x3700
      [   34.516094]  ? __netif_receive_skb+0x1f/0x1a0
      [   34.516629]  ? virtnet_probe+0x1b40/0x1b40
      [   34.517153]  ? __stable_node_chain+0x4d0/0x850
      [   34.517684]  ? kfree+0x9a/0x180
      [   34.518067]  ? __kasan_slab_free+0x171/0x190
      [   34.518582]  ? detach_buf+0x1df/0x650
      [   34.519061]  ? lapic_next_event+0x5a/0x90
      [   34.519539]  ? virtqueue_get_buf_ctx+0x280/0x7f0
      [   34.520093]  virtnet_poll+0x2df/0xd60
      [   34.520533]  ? receive_buf+0x3700/0x3700
      [   34.521027]  ? qdisc_watchdog_schedule_ns+0xd5/0x140
      [   34.521631]  ? htb_dequeue+0x1817/0x25f0
      [   34.522107]  ? sch_direct_xmit+0x142/0xf30
      [   34.522595]  ? virtqueue_napi_schedule+0x26/0x30
      [   34.523155]  net_rx_action+0x2f6/0xc50
      [   34.523601]  ? napi_complete_done+0x2f0/0x2f0
      [   34.524126]  ? kasan_check_read+0x11/0x20
      [   34.524608]  ? _raw_spin_lock+0x7d/0xd0
      [   34.525070]  ? _raw_spin_lock_bh+0xd0/0xd0
      [   34.525563]  ? kvm_guest_apic_eoi_write+0x6b/0x80
      [   34.526130]  ? apic_ack_irq+0x9e/0xe0
      [   34.526567]  __do_softirq+0x188/0x4b5
      [   34.527015]  irq_exit+0x151/0x180
      [   34.527417]  do_IRQ+0xdb/0x150
      [   34.527783]  common_interrupt+0xf/0xf
      [   34.528223]  </IRQ>
      
      This patch makes sure that skb->prev is set to NULL when entering
      netem_enqueue.
      
      Cc: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Fixes: 68d2f84a1368 ("net: gro: properly remove skb from list")
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8dd57cc3
    • Heiner Kallweit's avatar
      net: phy: don't allow __set_phy_supported to add unsupported modes · 4f384d94
      Heiner Kallweit authored
      [ Upstream commit d2a36971ef595069b7a600d1144c2e0881a930a1 ]
      
      Currently __set_phy_supported allows to add modes w/o checking whether
      the PHY supports them. This is wrong, it should never add modes but
      only remove modes we don't want to support.
      
      The commit marked as fixed didn't do anything wrong, it just copied
      existing functionality to the helper which is being fixed now.
      
      Fixes: f3a6bd39 ("phylib: Add phy_set_max_speed helper")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f384d94
    • Tarick Bedeir's avatar
      net/mlx4_core: Correctly set PFC param if global pause is turned off. · 5765610c
      Tarick Bedeir authored
      [ Upstream commit bd5122cd1e0644d8bd8dd84517c932773e999766 ]
      
      rx_ppp and tx_ppp can be set between 0 and 255, so don't clamp to 1.
      
      Fixes: 6e8814ceb7e8 ("net/mlx4_en: Fix mixed PFC and Global pause user control requests")
      Signed-off-by: default avatarTarick Bedeir <tarick@google.com>
      Reviewed-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5765610c
    • Su Yanjun's avatar
      net: 8139cp: fix a BUG triggered by changing mtu with network traffic · 25a445d3
      Su Yanjun authored
      [ Upstream commit a5d4a89245ead1f37ed135213653c5beebea4237 ]
      
      When changing mtu many times with traffic, a bug is triggered:
      
      [ 1035.684037] kernel BUG at lib/dynamic_queue_limits.c:26!
      [ 1035.684042] invalid opcode: 0000 [#1] SMP
      [ 1035.684049] Modules linked in: loop binfmt_misc 8139cp(OE) macsec
      tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag tcp_lp
      fuse uinput xt_CHECKSUM iptable_mangle ipt_MASQUERADE
      nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
      nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun
      bridge stp llc ebtable_filter ebtables ip6table_filter devlink
      ip6_tables iptable_filter sunrpc snd_hda_codec_generic snd_hda_intel
      snd_hda_codec snd_hda_core snd_hwdep ppdev snd_seq iosf_mbi crc32_pclmul
      parport_pc snd_seq_device ghash_clmulni_intel parport snd_pcm
      aesni_intel joydev lrw snd_timer virtio_balloon sg gf128mul glue_helper
      ablk_helper cryptd snd soundcore i2c_piix4 pcspkr ip_tables xfs
      libcrc32c sr_mod sd_mod cdrom crc_t10dif crct10dif_generic ata_generic
      [ 1035.684102]  pata_acpi virtio_console qxl drm_kms_helper syscopyarea
      sysfillrect sysimgblt floppy fb_sys_fops crct10dif_pclmul
      crct10dif_common ttm crc32c_intel serio_raw ata_piix drm libata 8139too
      virtio_pci drm_panel_orientation_quirks virtio_ring virtio mii dm_mirror
      dm_region_hash dm_log dm_mod [last unloaded: 8139cp]
      [ 1035.684132] CPU: 9 PID: 25140 Comm: if-mtu-change Kdump: loaded
      Tainted: G           OE  ------------ T 3.10.0-957.el7.x86_64 #1
      [ 1035.684134] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      [ 1035.684136] task: ffff8f59b1f5a080 ti: ffff8f5a2e32c000 task.ti:
      ffff8f5a2e32c000
      [ 1035.684149] RIP: 0010:[<ffffffffba3a40d0>]  [<ffffffffba3a40d0>]
      dql_completed+0x180/0x190
      [ 1035.684162] RSP: 0000:ffff8f5a75483e50  EFLAGS: 00010093
      [ 1035.684162] RAX: 00000000000000c2 RBX: ffff8f5a6f91c000 RCX:
      0000000000000000
      [ 1035.684162] RDX: 0000000000000000 RSI: 0000000000000184 RDI:
      ffff8f599fea3ec0
      [ 1035.684162] RBP: ffff8f5a75483ea8 R08: 00000000000000c2 R09:
      0000000000000000
      [ 1035.684162] R10: 00000000000616ef R11: ffff8f5a75483b56 R12:
      ffff8f599fea3e00
      [ 1035.684162] R13: 0000000000000001 R14: 0000000000000000 R15:
      0000000000000184
      [ 1035.684162] FS:  00007fa8434de740(0000) GS:ffff8f5a75480000(0000)
      knlGS:0000000000000000
      [ 1035.684162] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1035.684162] CR2: 00000000004305d0 CR3: 000000024eb66000 CR4:
      00000000001406e0
      [ 1035.684162] Call Trace:
      [ 1035.684162]  <IRQ>
      [ 1035.684162]  [<ffffffffc08cbaf8>] ? cp_interrupt+0x478/0x580 [8139cp]
      [ 1035.684162]  [<ffffffffba14a294>]
      __handle_irq_event_percpu+0x44/0x1c0
      [ 1035.684162]  [<ffffffffba14a442>] handle_irq_event_percpu+0x32/0x80
      [ 1035.684162]  [<ffffffffba14a4cc>] handle_irq_event+0x3c/0x60
      [ 1035.684162]  [<ffffffffba14db29>] handle_fasteoi_irq+0x59/0x110
      [ 1035.684162]  [<ffffffffba02e554>] handle_irq+0xe4/0x1a0
      [ 1035.684162]  [<ffffffffba7795dd>] do_IRQ+0x4d/0xf0
      [ 1035.684162]  [<ffffffffba76b362>] common_interrupt+0x162/0x162
      [ 1035.684162]  <EOI>
      [ 1035.684162]  [<ffffffffba0c2ae4>] ? __wake_up_bit+0x24/0x70
      [ 1035.684162]  [<ffffffffba1e46f5>] ? do_set_pte+0xd5/0x120
      [ 1035.684162]  [<ffffffffba1b64fb>] unlock_page+0x2b/0x30
      [ 1035.684162]  [<ffffffffba1e4879>] do_read_fault.isra.61+0x139/0x1b0
      [ 1035.684162]  [<ffffffffba1e9134>] handle_pte_fault+0x2f4/0xd10
      [ 1035.684162]  [<ffffffffba1ebc6d>] handle_mm_fault+0x39d/0x9b0
      [ 1035.684162]  [<ffffffffba76f5e3>] __do_page_fault+0x203/0x500
      [ 1035.684162]  [<ffffffffba76f9c6>] trace_do_page_fault+0x56/0x150
      [ 1035.684162]  [<ffffffffba76ef42>] do_async_page_fault+0x22/0xf0
      [ 1035.684162]  [<ffffffffba76b788>] async_page_fault+0x28/0x30
      [ 1035.684162] Code: 54 c7 47 54 ff ff ff ff 44 0f 49 ce 48 8b 35 48 2f
      9c 00 48 89 77 58 e9 fe fe ff ff 0f 1f 80 00 00 00 00 41 89 d1 e9 ef fe
      ff ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 55 8d 42 ff 48
      [ 1035.684162] RIP  [<ffffffffba3a40d0>] dql_completed+0x180/0x190
      [ 1035.684162]  RSP <ffff8f5a75483e50>
      
      It's not the same as in 7fe0ee09 patch described.
      As 8139cp uses shared irq mode, other device irq will trigger
      cp_interrupt to execute.
      
      cp_change_mtu
       -> cp_close
       -> cp_open
      
      In cp_close routine  just before free_irq(), some interrupt may occur.
      In my environment, cp_interrupt exectutes and IntrStatus is 0x4,
      exactly TxOk. That will cause cp_tx to wake device queue.
      
      As device queue is started, cp_start_xmit and cp_open will run at same
      time which will cause kernel BUG.
      
      For example:
      [#] for tx descriptor
      
      At start:
      
      [#][#][#]
      num_queued=3
      
      After cp_init_hw->cp_start_hw->netdev_reset_queue:
      
      [#][#][#]
      num_queued=0
      
      When 8139cp starts to work then cp_tx will check
      num_queued mismatchs the complete_bytes.
      
      The patch will check IntrMask before check IntrStatus in cp_interrupt.
      When 8139cp interrupt is disabled, just return.
      Signed-off-by: default avatarSu Yanjun <suyj.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      25a445d3
    • Stefano Brivio's avatar
      ipv6: Check available headroom in ip6_xmit() even without options · 901936a1
      Stefano Brivio authored
      [ Upstream commit 66033f47ca60294a95fc85ec3a3cc909dab7b765 ]
      
      Even if we send an IPv6 packet without options, MAX_HEADER might not be
      enough to account for the additional headroom required by alignment of
      hardware headers.
      
      On a configuration without HYPERV_NET, WLAN, AX25, and with IPV6_TUNNEL,
      sending short SCTP packets over IPv4 over L2TP over IPv6, we start with
      100 bytes of allocated headroom in sctp_packet_transmit(), end up with 54
      bytes after l2tp_xmit_skb(), and 14 bytes in ip6_finish_output2().
      
      Those would be enough to append our 14 bytes header, but we're going to
      align that to 16 bytes, and write 2 bytes out of the allocated slab in
      neigh_hh_output().
      
      KASan says:
      
      [  264.967848] ==================================================================
      [  264.967861] BUG: KASAN: slab-out-of-bounds in ip6_finish_output2+0x1aec/0x1c70
      [  264.967866] Write of size 16 at addr 000000006af1c7fe by task netperf/6201
      [  264.967870]
      [  264.967876] CPU: 0 PID: 6201 Comm: netperf Not tainted 4.20.0-rc4+ #1
      [  264.967881] Hardware name: IBM 2827 H43 400 (z/VM 6.4.0)
      [  264.967887] Call Trace:
      [  264.967896] ([<00000000001347d6>] show_stack+0x56/0xa0)
      [  264.967903]  [<00000000017e379c>] dump_stack+0x23c/0x290
      [  264.967912]  [<00000000007bc594>] print_address_description+0xf4/0x290
      [  264.967919]  [<00000000007bc8fc>] kasan_report+0x13c/0x240
      [  264.967927]  [<000000000162f5e4>] ip6_finish_output2+0x1aec/0x1c70
      [  264.967935]  [<000000000163f890>] ip6_finish_output+0x430/0x7f0
      [  264.967943]  [<000000000163fe44>] ip6_output+0x1f4/0x580
      [  264.967953]  [<000000000163882a>] ip6_xmit+0xfea/0x1ce8
      [  264.967963]  [<00000000017396e2>] inet6_csk_xmit+0x282/0x3f8
      [  264.968033]  [<000003ff805fb0ba>] l2tp_xmit_skb+0xe02/0x13e0 [l2tp_core]
      [  264.968037]  [<000003ff80631192>] l2tp_eth_dev_xmit+0xda/0x150 [l2tp_eth]
      [  264.968041]  [<0000000001220020>] dev_hard_start_xmit+0x268/0x928
      [  264.968069]  [<0000000001330e8e>] sch_direct_xmit+0x7ae/0x1350
      [  264.968071]  [<000000000122359c>] __dev_queue_xmit+0x2b7c/0x3478
      [  264.968075]  [<00000000013d2862>] ip_finish_output2+0xce2/0x11a0
      [  264.968078]  [<00000000013d9b14>] ip_finish_output+0x56c/0x8c8
      [  264.968081]  [<00000000013ddd1e>] ip_output+0x226/0x4c0
      [  264.968083]  [<00000000013dbd6c>] __ip_queue_xmit+0x894/0x1938
      [  264.968100]  [<000003ff80bc3a5c>] sctp_packet_transmit+0x29d4/0x3648 [sctp]
      [  264.968116]  [<000003ff80b7bf68>] sctp_outq_flush_ctrl.constprop.5+0x8d0/0xe50 [sctp]
      [  264.968131]  [<000003ff80b7c716>] sctp_outq_flush+0x22e/0x7d8 [sctp]
      [  264.968146]  [<000003ff80b35c68>] sctp_cmd_interpreter.isra.16+0x530/0x6800 [sctp]
      [  264.968161]  [<000003ff80b3410a>] sctp_do_sm+0x222/0x648 [sctp]
      [  264.968177]  [<000003ff80bbddac>] sctp_primitive_ASSOCIATE+0xbc/0xf8 [sctp]
      [  264.968192]  [<000003ff80b93328>] __sctp_connect+0x830/0xc20 [sctp]
      [  264.968208]  [<000003ff80bb11ce>] sctp_inet_connect+0x2e6/0x378 [sctp]
      [  264.968212]  [<0000000001197942>] __sys_connect+0x21a/0x450
      [  264.968215]  [<000000000119aff8>] sys_socketcall+0x3d0/0xb08
      [  264.968218]  [<000000000184ea7a>] system_call+0x2a2/0x2c0
      
      [...]
      
      Just like ip_finish_output2() does for IPv4, check that we have enough
      headroom in ip6_xmit(), and reallocate it if we don't.
      
      This issue is older than git history.
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      901936a1
  2. 13 Dec, 2018 29 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.145 · 9c2f007c
      Greg Kroah-Hartman authored
      9c2f007c
    • Stefan Agner's avatar
      kbuild: allow to use GCC toolchain not in Clang search path · 4c219af4
      Stefan Agner authored
      (commit ef8c4ed9db80261f397f0c0bf723684601ae3b52 upstream)
      
      When using a GCC cross toolchain which is not in a compiled in
      Clang search path, Clang reverts to the system assembler and
      linker. This leads to assembler or linker errors, depending on
      which tool is first used for a given architecture.
      
      It seems that Clang is not searching $PATH for a matching
      assembler or linker.
      
      Make sure that Clang picks up the correct assembler or linker by
      passing the cross compilers bin directory as search path.
      
      This allows to use Clang provided by distributions with GCC
      toolchains not in /usr/bin.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/78Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Reviewed-and-tested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      [ND: adjusted to context, due to adjusting the context of my previous
      backport of upstream's ae6b289a]
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c219af4
    • Nick Desaulniers's avatar
      kbuild: fix linker feature test macros when cross compiling with Clang · 51d137ca
      Nick Desaulniers authored
      (commit 86a9df59 upstream)
      
      I was not seeing my linker flags getting added when using ld-option when
      cross compiling with Clang. Upon investigation, this seems to be due to
      a difference in how GCC vs Clang handle cross compilation.
      
      GCC is configured at build time to support one backend, that is implicit
      when compiling.  Clang is explicit via the use of `-target <triple>` and
      ships with all supported backends by default.
      
      GNU Make feature test macros that compile then link will always fail
      when cross compiling with Clang unless Clang's triple is passed along to
      the compiler. For example:
      
      $ clang -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      aarch64-linux-android/bin/ld:
      unknown architecture of input file `temp.o' is incompatible with
      aarch64 output
      aarch64-linux-android/bin/ld:
      warning: cannot find entry symbol _start; defaulting to
      0000000000400078
      $ echo $?
      1
      
      $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      aarch64-linux-android/bin/ld:
      warning: cannot find entry symbol _start; defaulting to 00000000004002e4
      $ echo $?
      0
      
      This causes conditional checks that invoke $(CC) without the target
      triple, then $(LD) on the result, to always fail.
      Suggested-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      [ND: readjusted for context]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51d137ca
    • Emmanuel Grumbach's avatar
      mac80211: ignore NullFunc frames in the duplicate detection · fd54ea70
      Emmanuel Grumbach authored
      commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream.
      
      NullFunc packets should never be duplicate just like
      QoS-NullFunc packets.
      
      We saw a client that enters / exits power save with
      NullFunc frames (and not with QoS-NullFunc) despite the
      fact that the association supports HT.
      This specific client also re-uses a non-zero sequence number
      for different NullFunc frames.
      At some point, the client had to send a retransmission of
      the NullFunc frame and we dropped it, leading to a
      misalignment in the power save state.
      Fix this by never consider a NullFunc frame as duplicate,
      just like we do for QoS NullFunc frames.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd54ea70
    • Felix Fietkau's avatar
      mac80211: fix reordering of buffered broadcast packets · db32c245
      Felix Fietkau authored
      commit 9ec1190d065998650fd9260dea8cf3e1f56c0e8c upstream.
      
      If the buffered broadcast queue contains packets, letting new packets bypass
      that queue can lead to heavy reordering, since the driver is probably throttling
      transmission of buffered multicast packets after beacons.
      
      Keep buffering packets until the buffer has been cleared (and no client
      is in powersave mode).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db32c245
    • Felix Fietkau's avatar
      mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext · 7df29ead
      Felix Fietkau authored
      commit a317e65face482371de30246b6494feb093ff7f9 upstream.
      
      Make it behave like regular ieee80211_tx_status calls, except for the lack of
      filtered frame processing.
      This fixes spurious low-ack triggered disconnections with powersave clients
      connected to an AP.
      
      Fixes: f027c2ac ("mac80211: add ieee80211_tx_status_noskb")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7df29ead
    • Ben Greear's avatar
      mac80211: Clear beacon_int in ieee80211_do_stop · 554eac28
      Ben Greear authored
      commit 5c21e8100dfd57c806e833ae905e26efbb87840f upstream.
      
      This fixes stale beacon-int values that would keep a netdev
      from going up.
      
      To reproduce:
      
      Create two VAP on one radio.
      vap1 has beacon-int 100, start it.
      vap2 has beacon-int 240, start it (and it will fail
        because beacon-int mismatch).
      reconfigure vap2 to have beacon-int 100 and start it.
        It will fail because the stale beacon-int 240 will be used
        in the ifup path and hostapd never gets a chance to set the
        new beacon interval.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      554eac28
    • Vasyl Vavrychuk's avatar
      mac80211_hwsim: Timer should be initialized before device registered · 3a492ce1
      Vasyl Vavrychuk authored
      commit a1881c9b8a1edef0a5ae1d5c1b61406fe3402114 upstream.
      
      Otherwise if network manager starts configuring Wi-Fi interface
      immidiatelly after getting notification of its creation, we will get
      NULL pointer dereference:
      
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: [<ffffffff95ae94c8>] hrtimer_active+0x28/0x50
        ...
        Call Trace:
         [<ffffffff95ae9997>] ? hrtimer_try_to_cancel+0x27/0x110
         [<ffffffff95ae9a95>] ? hrtimer_cancel+0x15/0x20
         [<ffffffffc0803bf0>] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim]
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVasyl Vavrychuk <vasyl.vavrychuk@globallogic.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a492ce1
    • Macpaul Lin's avatar
      kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var() · 6d861927
      Macpaul Lin authored
      commit dada6a43b0402eba438a17ac86fdc64ac56a4607 upstream.
      
      This patch is trying to fix KE issue due to
      "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198"
      reported by Syzkaller scan."
      
      [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198
      [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0
      [26364:syz-executor0]Call trace:
      [26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470
      [26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30
      [26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128
      [26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8
      [26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390
      [26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20
      [26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198
      [26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270
      [26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90
      [26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158
      [26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8
      [26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0
      [26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0
      [26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8
      [26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208
      [26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:report&]The buggy address belongs to the variable:
      [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:report&]Memory state around the buggy address:
      [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa
      [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
      [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
      [26364:syz-executor0][name:report&]                                       ^
      [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
      [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint
      [26364:syz-executor0]------------[cut here]------------
      
      After checking the source code, we've found there might be an out-of-bounds
      access to "config[len - 1]" array when the variable "len" is zero.
      Signed-off-by: default avatarMacpaul Lin <macpaul@gmail.com>
      Acked-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d861927
    • Chanho Park's avatar
      tty: do not set TTY_IO_ERROR flag if console port · 9696ca90
      Chanho Park authored
      commit 2a48602615e0a2f563549c7d5c8d507f904cf96e upstream.
      
      Since Commit 761ed4a9 ('tty: serial_core: convert uart_close to use
      tty_port_close') and Commit 4dda864d ('tty: serial_core: Fix serial
      console crash on port shutdown), a serial port which is used as
      console can be stuck when logging out if there is a remained process.
      After logged out, agetty will try to grab the serial port but it will
      be failed because the previous process did not release the port
      correctly. To fix this, TTY_IO_ERROR bit should not be enabled of
      tty_port_close if the port is console port.
      
      Reproduce step:
      - Run background processes from serial console
      $ while true; do sleep 10; done &
      
      - Log out
      $ logout
      -> Stuck
      
      - Read journal log by journalctl | tail
      Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0.
      Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0.
      Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty
      
      Fixes: 761ed4a9 ("tty: serial_core: convert uart_close to use tty_port_close")
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Signed-off-by: default avatarChanho Park <parkch98@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9696ca90
    • Peter Shih's avatar
      tty: serial: 8250_mtk: always resume the device in probe. · 32445bd5
      Peter Shih authored
      commit 100bc3e2bebf95506da57cbdf5f26b25f6da4c81 upstream.
      
      serial8250_register_8250_port calls uart_config_port, which calls
      config_port on the port before it tries to power on the port. So we need
      the port to be on before calling serial8250_register_8250_port. Change
      the code to always do a runtime resume in probe before registering port,
      and always do a runtime suspend in remove.
      
      This basically reverts the change in commit 68e5fc4a ("tty: serial:
      8250_mtk: use pm_runtime callbacks for enabling"), but still use
      pm_runtime callbacks.
      
      Fixes: 68e5fc4a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling")
      Signed-off-by: default avatarPeter Shih <pihsun@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32445bd5
    • Young Xiao's avatar
      staging: rtl8712: Fix possible buffer overrun · 902d410d
      Young Xiao authored
      commit 300cd664865bed5d50ae0a42fb4e3a6f415e8a10 upstream.
      
      In commit 8b7a13c3 ("staging: r8712u: Fix possible buffer
      overrun") we fix a potential off by one by making the limit smaller.
      The better fix is to make the buffer larger.  This makes it match up
      with the similar code in other drivers.
      
      Fixes: 8b7a13c3 ("staging: r8712u: Fix possible buffer overrun")
      Signed-off-by: default avatarYoung Xiao <YangX92@hotmail.com>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      902d410d
    • Paulo Alcantara's avatar
      cifs: Fix separator when building path from dentry · fcfc7639
      Paulo Alcantara authored
      commit c988de29ca161823db6a7125e803d597ef75b49c upstream.
      
      Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for
      prefixpath too. Fixes a bug with smb1 UNIX extensions.
      
      Fixes: a6b5058f ("fs/cifs: make share unaccessible at root level mountable")
      Signed-off-by: default avatarPaulo Alcantara <palcantara@suse.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcfc7639
    • Greg Kroah-Hartman's avatar
      Staging: lustre: remove two build warnings · 2f5b7679
      Greg Kroah-Hartman authored
      [for older kernels only, lustre has been removed from upstream]
      
      When someone writes:
      	strncpy(dest, source, sizeof(source));
      they really are just doing the same thing as:
      	strcpy(dest, source);
      but somehow they feel better because they are now using the "safe"
      version of the string functions.  Cargo-cult programming at its
      finest...
      
      gcc-8 rightfully warns you about doing foolish things like this.  Now
      that the stable kernels are all starting to be built using gcc-8, let's
      get rid of this warning so that we do not have to gaze at this horror.
      
      To dropt the warning, just convert the code to using strcpy() so that if
      someone really wants to audit this code and find all of the obvious
      problems, it will be easier to do so.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f5b7679
    • Stefan Hajnoczi's avatar
      vhost/vsock: fix use-after-free in network stack callers · 569fc4ff
      Stefan Hajnoczi authored
      [ Upstream commit 834e772c8db0c6a275d75315d90aba4ebbb1e249 ]
      
      If the network stack calls .send_pkt()/.cancel_pkt() during .release(),
      a struct vhost_vsock use-after-free is possible.  This occurs because
      .release() does not wait for other CPUs to stop using struct
      vhost_vsock.
      
      Switch to an RCU-enabled hashtable (indexed by guest CID) so that
      .release() can wait for other CPUs by calling synchronize_rcu().  This
      also eliminates vhost_vsock_lock acquisition in the data path so it
      could have a positive effect on performance.
      
      This is CVE-2018-14625 "kernel: use-after-free Read in vhost_transport_send_pkt".
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com
      Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
      Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      569fc4ff
    • Gao feng's avatar
      vsock: lookup and setup guest_cid inside vhost_vsock_lock · 2d5a1b31
      Gao feng authored
      [ Upstream commit 6c083c2b ]
      
      Multi vsocks may setup the same cid at the same time.
      Signed-off-by: default avatarGao feng <omarapazanadi@gmail.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2d5a1b31
    • Kees Cook's avatar
      swiotlb: clean up reporting · adcc5726
      Kees Cook authored
      commit 7d63fb3af87aa67aa7d24466e792f9d7c57d8e79 upstream.
      
      This removes needless use of '%p', and refactors the printk calls to
      use pr_*() helpers instead.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      [bwh: Backported to 4.9:
       - Adjust filename
       - Remove "swiotlb: " prefix from an additional log message]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      adcc5726
    • Jens Axboe's avatar
      sr: pass down correctly sized SCSI sense buffer · cb101349
      Jens Axboe authored
      commit f7068114d45ec55996b9040e98111afa56e010fe upstream.
      
      We're casting the CDROM layer request_sense to the SCSI sense
      buffer, but the former is 64 bytes and the latter is 96 bytes.
      As we generally allocate these on the stack, we end up blowing
      up the stack.
      
      Fix this by wrapping the scsi_execute() call with a properly
      sized sense buffer, and copying back the bits for the CDROM
      layer.
      Reported-by: default avatarPiotr Gabriel Kosinski <pg.kosinski@gmail.com>
      Reported-by: default avatarDaniel Shapira <daniel@twistlock.com>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Fixes: 82ed4db4 ("block: split scsi_request out of struct request")
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      [bwh: Despite what the "Fixes" field says, a buffer overrun was already
       possible if the sense data was really > 64 bytes long.
       Backported to 4.9:
       - We always need to allocate a sense buffer in order to call
         scsi_normalize_sense()
       - Remove the existing conditional heap-allocation of the sense buffer]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cb101349
    • Mathias Nyman's avatar
      xhci: Prevent U1/U2 link pm states if exit latency is too long · d65afda6
      Mathias Nyman authored
      commit 0472bf06c6fd33c1a18aaead4c8f91e5a03d8d7b upstream.
      
      Don't allow USB3 U1 or U2 if the latency to wake up from the U-state
      reaches the service interval for a periodic endpoint.
      
      This is according to xhci 1.1 specification section 4.23.5.2 extra note:
      
      "Software shall ensure that a device is prevented from entering a U-state
       where its worst case exit latency approaches the ESIT."
      
      Allowing too long exit latencies for periodic endpoint confuses xHC
      internal scheduling, and new devices may fail to enumerate with a
      "Not enough bandwidth for new device state" error from the host.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d65afda6
    • Bin Liu's avatar
      dmaengine: cppi41: delete channel from pending list when stop channel · 1f717070
      Bin Liu authored
      commit 59861547ec9a9736e7882f6fb0c096a720ff811a upstream.
      
      The driver defines three states for a cppi channel.
      - idle: .chan_busy == 0 && not in .pending list
      - pending: .chan_busy == 0 && in .pending list
      - busy: .chan_busy == 1 && not in .pending list
      
      There are cases in which the cppi channel could be in the pending state
      when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
      is called.
      
      cppi41_stop_chan() has a bug for these cases to set channels to idle state.
      It only checks the .chan_busy flag, but not the .pending list, then later
      when cppi41_runtime_resume() is called the channels in .pending list will
      be transitioned to busy state.
      
      Removing channels from the .pending list solves the problem.
      
      Fixes: 975faaeb ("dma: cppi41: start tear down only if channel is busy")
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f717070
    • Chuck Lever's avatar
      SUNRPC: Fix leak of krb5p encode pages · ce4a99ac
      Chuck Lever authored
      commit 8dae5398ab1ac107b1517e8195ed043d5f422bd0 upstream.
      
      call_encode can be invoked more than once per RPC call. Ensure that
      each call to gss_wrap_req_priv does not overwrite pointers to
      previously allocated memory.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce4a99ac
    • Halil Pasic's avatar
      virtio/s390: fix race in ccw_io_helper() · 95e3e514
      Halil Pasic authored
      commit 78b1a52e05c9db11d293342e8d6d8a230a04b4e7 upstream.
      
      While ccw_io_helper() seems like intended to be exclusive in a sense that
      it is supposed to facilitate I/O for at most one thread at any given
      time, there is actually nothing ensuring that threads won't pile up at
      vcdev->wait_q. If they do, all threads get woken up and see the status
      that belongs to some other request than their own. This can lead to bugs.
      For an example see:
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432
      
      This race normally does not cause any problems. The operations provided
      by struct virtio_config_ops are usually invoked in a well defined
      sequence, normally don't fail, and are normally used quite infrequent
      too.
      
      Yet, if some of the these operations are directly triggered via sysfs
      attributes, like in the case described by the referenced bug, userspace
      is given an opportunity to force races by increasing the frequency of the
      given operations.
      
      Let us fix the problem by ensuring, that for each device, we finish
      processing the previous request before starting with a new one.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Cc: stable@vger.kernel.org
      Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95e3e514
    • Halil Pasic's avatar
      virtio/s390: avoid race on vcdev->config · 92054f4d
      Halil Pasic authored
      commit 2448a299ec416a80f699940a86f4a6d9a4f643b1 upstream.
      
      Currently we have a race on vcdev->config in virtio_ccw_get_config() and
      in virtio_ccw_set_config().
      
      This normally does not cause problems, as these are usually infrequent
      operations. However, for some devices writing to/reading from the config
      space can be triggered through sysfs attributes. For these, userspace can
      force the race by increasing the frequency.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Cc: stable@vger.kernel.org
      Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92054f4d
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570 · 5e51318e
      Takashi Iwai authored
      commit 54947cd64c1b8290f64bb2958e343c07270e3a58 upstream.
      
      We've got a regression report for some Thinkpad models (at least
      T570s) which shows the too low speaker output volume.  The bisection
      leaded to the commit 61fcf8ec ("ALSA: hda/realtek - Enable Thinkpad
      Dock device for ALC298 platform"), and it's basically adding the two
      pin configurations for the dock, and looks harmless.
      
      The real culprit seems, though, that the DAC assignment for the
      speaker pin is implicitly assumed on these devices, i.e. pin NID 0x14
      to be coupled with DAC NID 0x03.  When more pins are configured by the
      commit above, the auto-parser changes the DAC assignment, and this
      resulted in the regression.
      
      As a workaround, just provide the fixed pin / DAC mapping table for
      this Thinkpad fixup function.  It's no generic solution, but the
      problem itself is pretty much device-specific, so must be good
      enough.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1554304
      Fixes: 61fcf8ec ("ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform")
      Cc: <stable@vger.kernel.org>
      Reported-and-tested-by: default avatarJeremy Cline <jcline@redhat.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e51318e
    • Takashi Iwai's avatar
      ALSA: pcm: Fix interval evaluation with openmin/max · 1474395b
      Takashi Iwai authored
      commit 5363857b916c1f48027e9b96ee8be8376bf20811 upstream.
      
      As addressed in alsa-lib (commit b420056604f0), we need to fix the
      case where the evaluation of PCM interval "(x x+1]" leading to
      -EINVAL.  After applying rules, such an interval may be translated as
      "(x x+1)".
      
      Fixes: ff2d6acdf6f1 ("ALSA: pcm: Fix snd_interval_refine first/last with open min/max")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1474395b
    • Takashi Iwai's avatar
      ALSA: pcm: Call snd_pcm_unlink() conditionally at closing · ba9890ac
      Takashi Iwai authored
      commit b51abed8355e5556886623b2772fa6b7598d2282 upstream.
      
      Currently the PCM core calls snd_pcm_unlink() always unconditionally
      at closing a stream.  However, since snd_pcm_unlink() invokes the
      global rwsem down, the lock can be easily contended.  More badly, when
      a thread runs in a high priority RT-FIFO, it may stall at spinning.
      
      Basically the call of snd_pcm_unlink() is required only for the linked
      streams that are already rare occasion.  For normal use cases, this
      code path is fairly superfluous.
      
      As an optimization (and also as a workaround for the RT problem
      above in normal situations without linked streams), this patch adds a
      check before calling snd_pcm_unlink() and calls it only when needed.
      Reported-by: default avatarChanho Min <chanho.min@lge.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba9890ac
    • Chanho Min's avatar
      ALSA: pcm: Fix starvation on down_write_nonblock() · ee8dce2b
      Chanho Min authored
      commit b888a5f713e4d17faaaff24316585a4eb07f35b7 upstream.
      
      Commit 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM
      stream") fixes deadlock for non-atomic PCM stream. But, This patch
      causes antother stuck.
      If writer is RT thread and reader is a normal thread, the reader
      thread will be difficult to get scheduled. It may not give chance to
      release readlocks and writer gets stuck for a long time if they are
      pinned to single cpu.
      
      The deadlock described in the previous commit is because the linux
      rwsem queues like a FIFO. So, we might need non-FIFO writelock, not
      non-block one.
      
      My suggestion is that the writer gives reader a chance to be scheduled
      by using the minimum msleep() instaed of spinning without blocking by
      writer. Also, The *_nonblock may be changed to *_nonfifo appropriately
      to this concept.
      In terms of performance, when trylock is failed, this minimum periodic
      msleep will have the same performance as the tick-based
      schedule()/wake_up_q().
      
      [ Although this has a fairly high performance penalty, the relevant
        code path became already rare due to the previous commit ("ALSA:
        pcm: Call snd_pcm_unlink() conditionally at closing").  That is, now
        this unconditional msleep appears only when using linked streams,
        and this must be a rare case.  So we accept this as a quick
        workaround until finding a more suitable one -- tiwai ]
      
      Fixes: 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream")
      Suggested-by: default avatarWonmin Jung <wonmin.jung@lge.com>
      Signed-off-by: default avatarChanho Min <chanho.min@lge.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee8dce2b
    • Kai-Heng Feng's avatar
      ALSA: hda: Add support for AMD Stoney Ridge · 46da53f3
      Kai-Heng Feng authored
      commit 3deef52ce10514ccdebba8e8ab85f9cebd0eb3f7 upstream.
      
      It's similar to other AMD audio devices, it also supports D3, which can
      save some power drain.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46da53f3
    • Hui Peng's avatar
      ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in card.c · 73000a4c
      Hui Peng authored
      commit 5f8cf712582617d523120df67d392059eaf2fc4b upstream.
      
      If a USB sound card reports 0 interfaces, an error condition is triggered
      and the function usb_audio_probe errors out. In the error path, there was a
      use-after-free vulnerability where the memory object of the card was first
      freed, followed by a decrement of the number of active chips. Moving the
      decrement above the atomic_dec fixes the UAF.
      
      [ The original problem was introduced in 3.1 kernel, while it was
        developed in a different form.  The Fixes tag below indicates the
        original commit but it doesn't mean that the patch is applicable
        cleanly. -- tiwai ]
      
      Fixes: 362e4e49 ("ALSA: usb-audio - clear chip->probing on error exit")
      Reported-by: default avatarHui Peng <benquike@gmail.com>
      Reported-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Signed-off-by: default avatarHui Peng <benquike@gmail.com>
      Signed-off-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73000a4c