1. 09 Aug, 2020 29 commits
    • Eric Dumazet's avatar
      tcp: md5: allow changing MD5 keys in all socket states · 8fa2fac6
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 1ca0fafd ]
      
      This essentially reverts commit 72123032 ("tcp: md5: reject TCP_MD5SIG
      or TCP_MD5SIG_EXT on established sockets")
      
      Mathieu reported that many vendors BGP implementations can
      actually switch TCP MD5 on established flows.
      
      Quoting Mathieu :
         Here is a list of a few network vendors along with their behavior
         with respect to TCP MD5:
      
         - Cisco: Allows for password to be changed, but within the hold-down
           timer (~180 seconds).
         - Juniper: When password is initially set on active connection it will
           reset, but after that any subsequent password changes no network
           resets.
         - Nokia: No notes on if they flap the tcp connection or not.
         - Ericsson/RedBack: Allows for 2 password (old/new) to co-exist until
           both sides are ok with new passwords.
         - Meta-Switch: Expects the password to be set before a connection is
           attempted, but no further info on whether they reset the TCP
           connection on a change.
         - Avaya: Disable the neighbor, then set password, then re-enable.
         - Zebos: Would normally allow the change when socket connected.
      
      We can revert my prior change because commit 9424e2e7 ("tcp: md5: fix potential
      overestimation of TCP option space") removed the leak of 4 kernel bytes to
      the wire that was the main reason for my patch.
      
      While doing my investigations, I found a bug when a MD5 key is changed, leading
      to these commits that stable teams want to consider before backporting this revert :
      
       Commit 6a2febec ("tcp: md5: add missing memory barriers in tcp_md5_do_add()/tcp_md5_hash_key()")
       Commit e6ced831 ("tcp: md5: refine tcp_md5_do_add()/tcp_md5_hash_key() barriers")
      
      Fixes: 72123032 "tcp: md5: reject TCP_MD5SIG or TCP_MD5SIG_EXT on established sockets"
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      8fa2fac6
    • Eric Dumazet's avatar
      tcp: md5: refine tcp_md5_do_add()/tcp_md5_hash_key() barriers · 511e9f80
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit e6ced831 ]
      
      My prior fix went a bit too far, according to Herbert and Mathieu.
      
      Since we accept that concurrent TCP MD5 lookups might see inconsistent
      keys, we can use READ_ONCE()/WRITE_ONCE() instead of smp_rmb()/smp_wmb()
      
      Clearing all key->key[] is needed to avoid possible KMSAN reports,
      if key->keylen is increased. Since tcp_md5_do_add() is not fast path,
      using __GFP_ZERO to clear all struct tcp_md5sig_key is simpler.
      
      data_race() was added in linux-5.8 and will prevent KCSAN reports,
      this can safely be removed in stable backports, if data_race() is
      not yet backported.
      
      v2: use data_race() both in tcp_md5_hash_key() and tcp_md5_do_add()
      
      Fixes: 6a2febec ("tcp: md5: add missing memory barriers in tcp_md5_do_add()/tcp_md5_hash_key()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Marco Elver <elver@google.com>
      Reviewed-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      511e9f80
    • Eric Dumazet's avatar
      tcp: md5: add missing memory barriers in tcp_md5_do_add()/tcp_md5_hash_key() · 55f02e44
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 6a2febec ]
      
      MD5 keys are read with RCU protection, and tcp_md5_do_add()
      might update in-place a prior key.
      
      Normally, typical RCU updates would allocate a new piece
      of memory. In this case only key->key and key->keylen might
      be updated, and we do not care if an incoming packet could
      see the old key, the new one, or some intermediate value,
      since changing the key on a live flow is known to be problematic
      anyway.
      
      We only want to make sure that in the case key->keylen
      is changed, cpus in tcp_md5_hash_key() wont try to use
      uninitialized data, or crash because key->keylen was
      read twice to feed sg_init_one() and ahash_request_set_crypt()
      
      Fixes: 9ea88a15 ("tcp: md5: check md5 signature without socket lock")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      55f02e44
    • Christoph Paasch's avatar
      tcp: make sure listeners don't initialize congestion-control state · 08f894c6
      Christoph Paasch authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit ce69e563 ]
      
      syzkaller found its way into setsockopt with TCP_CONGESTION "cdg".
      tcp_cdg_init() does a kcalloc to store the gradients. As sk_clone_lock
      just copies all the memory, the allocated pointer will be copied as
      well, if the app called setsockopt(..., TCP_CONGESTION) on the listener.
      If now the socket will be destroyed before the congestion-control
      has properly been initialized (through a call to tcp_init_transfer), we
      will end up freeing memory that does not belong to that particular
      socket, opening the door to a double-free:
      
      [   11.413102] ==================================================================
      [   11.414181] BUG: KASAN: double-free or invalid-free in tcp_cleanup_congestion_control+0x58/0xd0
      [   11.415329]
      [   11.415560] CPU: 3 PID: 4884 Comm: syz-executor.5 Not tainted 5.8.0-rc2 #80
      [   11.416544] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      [   11.418148] Call Trace:
      [   11.418534]  <IRQ>
      [   11.418834]  dump_stack+0x7d/0xb0
      [   11.419297]  print_address_description.constprop.0+0x1a/0x210
      [   11.422079]  kasan_report_invalid_free+0x51/0x80
      [   11.423433]  __kasan_slab_free+0x15e/0x170
      [   11.424761]  kfree+0x8c/0x230
      [   11.425157]  tcp_cleanup_congestion_control+0x58/0xd0
      [   11.425872]  tcp_v4_destroy_sock+0x57/0x5a0
      [   11.426493]  inet_csk_destroy_sock+0x153/0x2c0
      [   11.427093]  tcp_v4_syn_recv_sock+0xb29/0x1100
      [   11.427731]  tcp_get_cookie_sock+0xc3/0x4a0
      [   11.429457]  cookie_v4_check+0x13d0/0x2500
      [   11.433189]  tcp_v4_do_rcv+0x60e/0x780
      [   11.433727]  tcp_v4_rcv+0x2869/0x2e10
      [   11.437143]  ip_protocol_deliver_rcu+0x23/0x190
      [   11.437810]  ip_local_deliver+0x294/0x350
      [   11.439566]  __netif_receive_skb_one_core+0x15d/0x1a0
      [   11.441995]  process_backlog+0x1b1/0x6b0
      [   11.443148]  net_rx_action+0x37e/0xc40
      [   11.445361]  __do_softirq+0x18c/0x61a
      [   11.445881]  asm_call_on_stack+0x12/0x20
      [   11.446409]  </IRQ>
      [   11.446716]  do_softirq_own_stack+0x34/0x40
      [   11.447259]  do_softirq.part.0+0x26/0x30
      [   11.447827]  __local_bh_enable_ip+0x46/0x50
      [   11.448406]  ip_finish_output2+0x60f/0x1bc0
      [   11.450109]  __ip_queue_xmit+0x71c/0x1b60
      [   11.451861]  __tcp_transmit_skb+0x1727/0x3bb0
      [   11.453789]  tcp_rcv_state_process+0x3070/0x4d3a
      [   11.456810]  tcp_v4_do_rcv+0x2ad/0x780
      [   11.457995]  __release_sock+0x14b/0x2c0
      [   11.458529]  release_sock+0x4a/0x170
      [   11.459005]  __inet_stream_connect+0x467/0xc80
      [   11.461435]  inet_stream_connect+0x4e/0xa0
      [   11.462043]  __sys_connect+0x204/0x270
      [   11.465515]  __x64_sys_connect+0x6a/0xb0
      [   11.466088]  do_syscall_64+0x3e/0x70
      [   11.466617]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   11.467341] RIP: 0033:0x7f56046dc469
      [   11.467844] Code: Bad RIP value.
      [   11.468282] RSP: 002b:00007f5604dccdd8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      [   11.469326] RAX: ffffffffffffffda RBX: 000000000068bf00 RCX: 00007f56046dc469
      [   11.470379] RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000004
      [   11.471311] RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000
      [   11.472286] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      [   11.473341] R13: 000000000041427c R14: 00007f5604dcd5c0 R15: 0000000000000003
      [   11.474321]
      [   11.474527] Allocated by task 4884:
      [   11.475031]  save_stack+0x1b/0x40
      [   11.475548]  __kasan_kmalloc.constprop.0+0xc2/0xd0
      [   11.476182]  tcp_cdg_init+0xf0/0x150
      [   11.476744]  tcp_init_congestion_control+0x9b/0x3a0
      [   11.477435]  tcp_set_congestion_control+0x270/0x32f
      [   11.478088]  do_tcp_setsockopt.isra.0+0x521/0x1a00
      [   11.478744]  __sys_setsockopt+0xff/0x1e0
      [   11.479259]  __x64_sys_setsockopt+0xb5/0x150
      [   11.479895]  do_syscall_64+0x3e/0x70
      [   11.480395]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   11.481097]
      [   11.481321] Freed by task 4872:
      [   11.481783]  save_stack+0x1b/0x40
      [   11.482230]  __kasan_slab_free+0x12c/0x170
      [   11.482839]  kfree+0x8c/0x230
      [   11.483240]  tcp_cleanup_congestion_control+0x58/0xd0
      [   11.483948]  tcp_v4_destroy_sock+0x57/0x5a0
      [   11.484502]  inet_csk_destroy_sock+0x153/0x2c0
      [   11.485144]  tcp_close+0x932/0xfe0
      [   11.485642]  inet_release+0xc1/0x1c0
      [   11.486131]  __sock_release+0xc0/0x270
      [   11.486697]  sock_close+0xc/0x10
      [   11.487145]  __fput+0x277/0x780
      [   11.487632]  task_work_run+0xeb/0x180
      [   11.488118]  __prepare_exit_to_usermode+0x15a/0x160
      [   11.488834]  do_syscall_64+0x4a/0x70
      [   11.489326]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Wei Wang fixed a part of these CDG-malloc issues with commit c1201444
      ("tcp: memset ca_priv data to 0 properly").
      
      This patch here fixes the listener-scenario: We make sure that listeners
      setting the congestion-control through setsockopt won't initialize it
      (thus CDG never allocates on listeners). For those who use AF_UNSPEC to
      reuse a socket, tcp_disconnect() is changed to cleanup afterwards.
      
      (The issue can be reproduced at least down to v4.4.x.)
      
      Cc: Wei Wang <weiwan@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Fixes: 2b0a8c9e ("tcp: add CDG congestion control")
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Signed-off-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>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      08f894c6
    • Sean Tranchetti's avatar
      genetlink: remove genl_bind · 5f83b838
      Sean Tranchetti authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 1e82a62f ]
      
      A potential deadlock can occur during registering or unregistering a
      new generic netlink family between the main nl_table_lock and the
      cb_lock where each thread wants the lock held by the other, as
      demonstrated below.
      
      1) Thread 1 is performing a netlink_bind() operation on a socket. As part
         of this call, it will call netlink_lock_table(), incrementing the
         nl_table_users count to 1.
      2) Thread 2 is registering (or unregistering) a genl_family via the
         genl_(un)register_family() API. The cb_lock semaphore will be taken for
         writing.
      3) Thread 1 will call genl_bind() as part of the bind operation to handle
         subscribing to GENL multicast groups at the request of the user. It will
         attempt to take the cb_lock semaphore for reading, but it will fail and
         be scheduled away, waiting for Thread 2 to finish the write.
      4) Thread 2 will call netlink_table_grab() during the (un)registration
         call. However, as Thread 1 has incremented nl_table_users, it will not
         be able to proceed, and both threads will be stuck waiting for the
         other.
      
      genl_bind() is a noop, unless a genl_family implements the mcast_bind()
      function to handle setting up family-specific multicast operations. Since
      no one in-tree uses this functionality as Cong pointed out, simply removing
      the genl_bind() function will remove the possibility for deadlock, as there
      is no attempt by Thread 1 above to take the cb_lock semaphore.
      
      Fixes: c380d9a7 ("genetlink: pass multicast bind/unbind to families")
      Suggested-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarSean Tranchetti <stranche@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      5f83b838
    • Martin Varghese's avatar
      net: Added pointer check for dst->ops->neigh_lookup in dst_neigh_lookup_skb · a7cc07b9
      Martin Varghese authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 394de110 ]
      
      The packets from tunnel devices (eg bareudp) may have only
      metadata in the dst pointer of skb. Hence a pointer check of
      neigh_lookup is needed in dst_neigh_lookup_skb
      
      Kernel crashes when packets from bareudp device is processed in
      the kernel neighbour subsytem.
      
      [  133.384484] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [  133.385240] #PF: supervisor instruction fetch in kernel mode
      [  133.385828] #PF: error_code(0x0010) - not-present page
      [  133.386603] PGD 0 P4D 0
      [  133.386875] Oops: 0010 [#1] SMP PTI
      [  133.387275] CPU: 0 PID: 5045 Comm: ping Tainted: G        W         5.8.0-rc2+ #15
      [  133.388052] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      [  133.391076] RIP: 0010:0x0
      [  133.392401] Code: Bad RIP value.
      [  133.394029] RSP: 0018:ffffb79980003d50 EFLAGS: 00010246
      [  133.396656] RAX: 0000000080000102 RBX: ffff9de2fe0d6600 RCX: ffff9de2fe5e9d00
      [  133.399018] RDX: 0000000000000000 RSI: ffff9de2fe5e9d00 RDI: ffff9de2fc21b400
      [  133.399685] RBP: ffff9de2fe5e9d00 R08: 0000000000000000 R09: 0000000000000000
      [  133.400350] R10: ffff9de2fbc6be22 R11: ffff9de2fe0d6600 R12: ffff9de2fc21b400
      [  133.401010] R13: ffff9de2fe0d6628 R14: 0000000000000001 R15: 0000000000000003
      [  133.401667] FS:  00007fe014918740(0000) GS:ffff9de2fec00000(0000) knlGS:0000000000000000
      [  133.402412] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  133.402948] CR2: ffffffffffffffd6 CR3: 000000003bb72000 CR4: 00000000000006f0
      [  133.403611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  133.404270] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  133.404933] Call Trace:
      [  133.405169]  <IRQ>
      [  133.405367]  __neigh_update+0x5a4/0x8f0
      [  133.405734]  arp_process+0x294/0x820
      [  133.406076]  ? __netif_receive_skb_core+0x866/0xe70
      [  133.406557]  arp_rcv+0x129/0x1c0
      [  133.406882]  __netif_receive_skb_one_core+0x95/0xb0
      [  133.407340]  process_backlog+0xa7/0x150
      [  133.407705]  net_rx_action+0x2af/0x420
      [  133.408457]  __do_softirq+0xda/0x2a8
      [  133.408813]  asm_call_on_stack+0x12/0x20
      [  133.409290]  </IRQ>
      [  133.409519]  do_softirq_own_stack+0x39/0x50
      [  133.410036]  do_softirq+0x50/0x60
      [  133.410401]  __local_bh_enable_ip+0x50/0x60
      [  133.410871]  ip_finish_output2+0x195/0x530
      [  133.411288]  ip_output+0x72/0xf0
      [  133.411673]  ? __ip_finish_output+0x1f0/0x1f0
      [  133.412122]  ip_send_skb+0x15/0x40
      [  133.412471]  raw_sendmsg+0x853/0xab0
      [  133.412855]  ? insert_pfn+0xfe/0x270
      [  133.413827]  ? vvar_fault+0xec/0x190
      [  133.414772]  sock_sendmsg+0x57/0x80
      [  133.415685]  __sys_sendto+0xdc/0x160
      [  133.416605]  ? syscall_trace_enter+0x1d4/0x2b0
      [  133.417679]  ? __audit_syscall_exit+0x1d9/0x280
      [  133.418753]  ? __prepare_exit_to_usermode+0x5d/0x1a0
      [  133.419819]  __x64_sys_sendto+0x24/0x30
      [  133.420848]  do_syscall_64+0x4d/0x90
      [  133.421768]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  133.422833] RIP: 0033:0x7fe013689c03
      [  133.423749] Code: Bad RIP value.
      [  133.424624] RSP: 002b:00007ffc7288f418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      [  133.425940] RAX: ffffffffffffffda RBX: 000056151fc63720 RCX: 00007fe013689c03
      [  133.427225] RDX: 0000000000000040 RSI: 000056151fc63720 RDI: 0000000000000003
      [  133.428481] RBP: 00007ffc72890b30 R08: 000056151fc60500 R09: 0000000000000010
      [  133.429757] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
      [  133.431041] R13: 000056151fc636e0 R14: 000056151fc616bc R15: 0000000000000080
      [  133.432481] Modules linked in: mpls_iptunnel act_mirred act_tunnel_key cls_flower sch_ingress veth mpls_router ip_tunnel bareudp ip6_udp_tunnel udp_tunnel macsec udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc xt_MASQUERADE iptable_nat xt_addrtype xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc ebtable_filter ebtables overlay ip6table_filter ip6_tables iptable_filter sunrpc ext4 mbcache jbd2 pcspkr i2c_piix4 virtio_balloon joydev ip_tables xfs libcrc32c ata_generic qxl pata_acpi drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ata_piix libata virtio_net net_failover virtio_console failover virtio_blk i2c_core virtio_pci virtio_ring serio_raw floppy virtio dm_mirror dm_region_hash dm_log dm_mod
      [  133.444045] CR2: 0000000000000000
      [  133.445082] ---[ end trace f4aeee1958fd1638 ]---
      [  133.446236] RIP: 0010:0x0
      [  133.447180] Code: Bad RIP value.
      [  133.448152] RSP: 0018:ffffb79980003d50 EFLAGS: 00010246
      [  133.449363] RAX: 0000000080000102 RBX: ffff9de2fe0d6600 RCX: ffff9de2fe5e9d00
      [  133.450835] RDX: 0000000000000000 RSI: ffff9de2fe5e9d00 RDI: ffff9de2fc21b400
      [  133.452237] RBP: ffff9de2fe5e9d00 R08: 0000000000000000 R09: 0000000000000000
      [  133.453722] R10: ffff9de2fbc6be22 R11: ffff9de2fe0d6600 R12: ffff9de2fc21b400
      [  133.455149] R13: ffff9de2fe0d6628 R14: 0000000000000001 R15: 0000000000000003
      [  133.456520] FS:  00007fe014918740(0000) GS:ffff9de2fec00000(0000) knlGS:0000000000000000
      [  133.458046] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  133.459342] CR2: ffffffffffffffd6 CR3: 000000003bb72000 CR4: 00000000000006f0
      [  133.460782] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  133.462240] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  133.463697] Kernel panic - not syncing: Fatal exception in interrupt
      [  133.465226] Kernel Offset: 0xfa00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      [  133.467025] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
      
      Fixes: aaa0c23c ("Fix dst_neigh_lookup/dst_neigh_lookup_skb return value handling bug")
      Signed-off-by: default avatarMartin Varghese <martin.varghese@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      a7cc07b9
    • Eric Dumazet's avatar
      llc: make sure applications use ARPHRD_ETHER · 8dd56653
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit a9b11101 ]
      
      syzbot was to trigger a bug by tricking AF_LLC with
      non sensible addr->sllc_arphrd
      
      It seems clear LLC requires an Ethernet device.
      
      Back in commit abf9d537 ("llc: add support for SO_BINDTODEVICE")
      Octavian Purdila added possibility for application to use a zero
      value for sllc_arphrd, convert it to ARPHRD_ETHER to not cause
      regressions on existing applications.
      
      BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:199 [inline]
      BUG: KASAN: use-after-free in list_empty include/linux/list.h:268 [inline]
      BUG: KASAN: use-after-free in waitqueue_active include/linux/wait.h:126 [inline]
      BUG: KASAN: use-after-free in wq_has_sleeper include/linux/wait.h:160 [inline]
      BUG: KASAN: use-after-free in skwq_has_sleeper include/net/sock.h:2092 [inline]
      BUG: KASAN: use-after-free in sock_def_write_space+0x642/0x670 net/core/sock.c:2813
      Read of size 8 at addr ffff88801e0b4078 by task ksoftirqd/3/27
      
      CPU: 3 PID: 27 Comm: ksoftirqd/3 Not tainted 5.5.0-rc1-syzkaller #0
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
      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_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
       __read_once_size include/linux/compiler.h:199 [inline]
       list_empty include/linux/list.h:268 [inline]
       waitqueue_active include/linux/wait.h:126 [inline]
       wq_has_sleeper include/linux/wait.h:160 [inline]
       skwq_has_sleeper include/net/sock.h:2092 [inline]
       sock_def_write_space+0x642/0x670 net/core/sock.c:2813
       sock_wfree+0x1e1/0x260 net/core/sock.c:1958
       skb_release_head_state+0xeb/0x260 net/core/skbuff.c:652
       skb_release_all+0x16/0x60 net/core/skbuff.c:663
       __kfree_skb net/core/skbuff.c:679 [inline]
       consume_skb net/core/skbuff.c:838 [inline]
       consume_skb+0xfb/0x410 net/core/skbuff.c:832
       __dev_kfree_skb_any+0xa4/0xd0 net/core/dev.c:2967
       dev_kfree_skb_any include/linux/netdevice.h:3650 [inline]
       e1000_unmap_and_free_tx_resource.isra.0+0x21b/0x3a0 drivers/net/ethernet/intel/e1000/e1000_main.c:1963
       e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3854 [inline]
       e1000_clean+0x4cc/0x1d10 drivers/net/ethernet/intel/e1000/e1000_main.c:3796
       napi_poll net/core/dev.c:6532 [inline]
       net_rx_action+0x508/0x1120 net/core/dev.c:6600
       __do_softirq+0x262/0x98c kernel/softirq.c:292
       run_ksoftirqd kernel/softirq.c:603 [inline]
       run_ksoftirqd+0x8e/0x110 kernel/softirq.c:595
       smpboot_thread_fn+0x6a3/0xa40 kernel/smpboot.c:165
       kthread+0x361/0x430 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      Allocated by task 8247:
       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_slab_alloc+0xf/0x20 mm/kasan/common.c:521
       slab_post_alloc_hook mm/slab.h:584 [inline]
       slab_alloc mm/slab.c:3320 [inline]
       kmem_cache_alloc+0x121/0x710 mm/slab.c:3484
       sock_alloc_inode+0x1c/0x1d0 net/socket.c:240
       alloc_inode+0x68/0x1e0 fs/inode.c:230
       new_inode_pseudo+0x19/0xf0 fs/inode.c:919
       sock_alloc+0x41/0x270 net/socket.c:560
       __sock_create+0xc2/0x730 net/socket.c:1384
       sock_create net/socket.c:1471 [inline]
       __sys_socket+0x103/0x220 net/socket.c:1513
       __do_sys_socket net/socket.c:1522 [inline]
       __se_sys_socket net/socket.c:1520 [inline]
       __ia32_sys_socket+0x73/0xb0 net/socket.c:1520
       do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline]
       do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408
       entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
      
      Freed by task 17:
       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]
       kmem_cache_free+0x86/0x320 mm/slab.c:3694
       sock_free_inode+0x20/0x30 net/socket.c:261
       i_callback+0x44/0x80 fs/inode.c:219
       __rcu_reclaim kernel/rcu/rcu.h:222 [inline]
       rcu_do_batch kernel/rcu/tree.c:2183 [inline]
       rcu_core+0x570/0x1540 kernel/rcu/tree.c:2408
       rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2417
       __do_softirq+0x262/0x98c kernel/softirq.c:292
      
      The buggy address belongs to the object at ffff88801e0b4000
       which belongs to the cache sock_inode_cache of size 1152
      The buggy address is located 120 bytes inside of
       1152-byte region [ffff88801e0b4000, ffff88801e0b4480)
      The buggy address belongs to the page:
      page:ffffea0000782d00 refcount:1 mapcount:0 mapping:ffff88807aa59c40 index:0xffff88801e0b4ffd
      raw: 00fffe0000000200 ffffea00008e6c88 ffffea0000782d48 ffff88807aa59c40
      raw: ffff88801e0b4ffd ffff88801e0b4000 0000000100000003 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88801e0b3f00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
       ffff88801e0b3f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88801e0b4000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                      ^
       ffff88801e0b4080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88801e0b4100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: abf9d537 ("llc: add support for SO_BINDTODEVICE")
      Signed-off-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>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      8dd56653
    • Xin Long's avatar
      l2tp: remove skb_dst_set() from l2tp_xmit_skb() · 661399a6
      Xin Long authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 27d53323 ]
      
      In the tx path of l2tp, l2tp_xmit_skb() calls skb_dst_set() to set
      skb's dst. However, it will eventually call inet6_csk_xmit() or
      ip_queue_xmit() where skb's dst will be overwritten by:
      
         skb_dst_set_noref(skb, dst);
      
      without releasing the old dst in skb. Then it causes dst/dev refcnt leak:
      
        unregister_netdevice: waiting for eth0 to become free. Usage count = 1
      
      This can be reproduced by simply running:
      
        # modprobe l2tp_eth && modprobe l2tp_ip
        # sh ./tools/testing/selftests/net/l2tp.sh
      
      So before going to inet6_csk_xmit() or ip_queue_xmit(), skb's dst
      should be dropped. This patch is to fix it by removing skb_dst_set()
      from l2tp_xmit_skb() and moving skb_dst_drop() into l2tp_xmit_core().
      
      Fixes: 3557baab ("[L2TP]: PPP over L2TP driver core")
      Reported-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarJames Chapman <jchapman@katalix.com>
      Tested-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      661399a6
    • Sabrina Dubroca's avatar
      ipv4: fill fl4_icmp_{type,code} in ping_v4_sendmsg · 1db1f9f3
      Sabrina Dubroca authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 5eff0690 ]
      
      IPv4 ping sockets don't set fl4.fl4_icmp_{type,code}, which leads to
      incomplete IPsec ACQUIRE messages being sent to userspace. Currently,
      both raw sockets and IPv6 ping sockets set those fields.
      
      Expected output of "ip xfrm monitor":
          acquire proto esp
            sel src 10.0.2.15/32 dst 8.8.8.8/32 proto icmp type 8 code 0 dev ens4
            policy src 10.0.2.15/32 dst 8.8.8.8/32
              <snip>
      
      Currently with ping sockets:
          acquire proto esp
            sel src 10.0.2.15/32 dst 8.8.8.8/32 proto icmp type 0 code 0 dev ens4
            policy src 10.0.2.15/32 dst 8.8.8.8/32
              <snip>
      
      The Libreswan test suite found this problem after Fedora changed the
      value for the sysctl net.ipv4.ping_group_range.
      
      Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind")
      Reported-by: default avatarPaul Wouters <pwouters@redhat.com>
      Tested-by: default avatarPaul Wouters <pwouters@redhat.com>
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      1db1f9f3
    • Davide Caratti's avatar
      bnxt_en: fix NULL dereference in case SR-IOV configuration fails · 1438e4bc
      Davide Caratti authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit c8b1d743 upstream.
      
      we need to set 'active_vfs' back to 0, if something goes wrong during the
      allocation of SR-IOV resources: otherwise, further VF configurations will
      wrongly assume that bp->pf.vf[x] are valid memory locations, and commands
      like the ones in the following sequence:
      
       # echo 2 >/sys/bus/pci/devices/${ADDR}/sriov_numvfs
       # ip link set dev ens1f0np0 up
       # ip link set dev ens1f0np0 vf 0 trust on
      
      will cause a kernel crash similar to this:
      
       bnxt_en 0000:3b:00.0: not enough MMIO resources for SR-IOV
       BUG: kernel NULL pointer dereference, address: 0000000000000014
       #PF: supervisor read access in kernel mode
       #PF: error_code(0x0000) - not-present page
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 43 PID: 2059 Comm: ip Tainted: G          I       5.8.0-rc2.upstream+ #871
       Hardware name: Dell Inc. PowerEdge R740/08D89F, BIOS 2.2.11 06/13/2019
       RIP: 0010:bnxt_set_vf_trust+0x5b/0x110 [bnxt_en]
       Code: 44 24 58 31 c0 e8 f5 fb ff ff 85 c0 0f 85 b6 00 00 00 48 8d 1c 5b 41 89 c6 b9 0b 00 00 00 48 c1 e3 04 49 03 9c 24 f0 0e 00 00 <8b> 43 14 89 c2 83 c8 10 83 e2 ef 45 84 ed 49 89 e5 0f 44 c2 4c 89
       RSP: 0018:ffffac6246a1f570 EFLAGS: 00010246
       RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000b
       RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff98b28f538900
       RBP: ffff98b28f538900 R08: 0000000000000000 R09: 0000000000000008
       R10: ffffffffb9515be0 R11: ffffac6246a1f678 R12: ffff98b28f538000
       R13: 0000000000000001 R14: 0000000000000000 R15: ffffffffc05451e0
       FS:  00007fde0f688800(0000) GS:ffff98baffd40000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000014 CR3: 000000104bb0a003 CR4: 00000000007606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       PKRU: 55555554
       Call Trace:
        do_setlink+0x994/0xfe0
        __rtnl_newlink+0x544/0x8d0
        rtnl_newlink+0x47/0x70
        rtnetlink_rcv_msg+0x29f/0x350
        netlink_rcv_skb+0x4a/0x110
        netlink_unicast+0x21d/0x300
        netlink_sendmsg+0x329/0x450
        sock_sendmsg+0x5b/0x60
        ____sys_sendmsg+0x204/0x280
        ___sys_sendmsg+0x88/0xd0
        __sys_sendmsg+0x5e/0xa0
        do_syscall_64+0x47/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.")
      Reported-by: default avatarFei Liu <feliu@redhat.com>
      CC: Jonathan Toppins <jtoppins@redhat.com>
      CC: Michael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Reviewed-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Acked-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      1438e4bc
    • Vineet Gupta's avatar
      ARC: elf: use right ELF_ARCH · 45df83ce
      Vineet Gupta authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit b7faf971 upstream.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      45df83ce
    • Vineet Gupta's avatar
      ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE · 68a84271
      Vineet Gupta authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit 00fdec98 upstream.
      
      Trap handler for syscall tracing reads EFA (Exception Fault Address),
      in case strace wants PC of trap instruction (EFA is not part of pt_regs
      as of current code).
      
      However this EFA read is racy as it happens after dropping to pure
      kernel mode (re-enabling interrupts). A taken interrupt could
      context-switch, trigger a different task's trap, clobbering EFA for this
      execution context.
      
      Fix this by reading EFA early, before re-enabling interrupts. A slight
      side benefit is de-duplication of FAKE_RET_FROM_EXCPN in trap handler.
      The trap handler is common to both ARCompact and ARCv2 builds too.
      
      This just came out of code rework/review and no real problem was reported
      but is clearly a potential problem specially for strace.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      68a84271
    • Tom Rix's avatar
      drm/radeon: fix double free · 3dc9ed81
      Tom Rix authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit 41855a89 upstream.
      
      clang static analysis flags this error
      
      drivers/gpu/drm/radeon/ci_dpm.c:5652:9: warning: Use of memory after it is freed [unix.Malloc]
                      kfree(rdev->pm.dpm.ps[i].ps_priv);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/gpu/drm/radeon/ci_dpm.c:5654:2: warning: Attempt to free released memory [unix.Malloc]
              kfree(rdev->pm.dpm.ps);
              ^~~~~~~~~~~~~~~~~~~~~~
      
      problem is reported in ci_dpm_fini, with these code blocks.
      
      	for (i = 0; i < rdev->pm.dpm.num_ps; i++) {
      		kfree(rdev->pm.dpm.ps[i].ps_priv);
      	}
      	kfree(rdev->pm.dpm.ps);
      
      The first free happens in ci_parse_power_table where it cleans up locally
      on a failure.  ci_dpm_fini also does a cleanup.
      
      	ret = ci_parse_power_table(rdev);
      	if (ret) {
      		ci_dpm_fini(rdev);
      		return ret;
      	}
      
      So remove the cleanup in ci_parse_power_table and
      move the num_ps calculation to inside the loop so ci_dpm_fini
      will know how many array elements to free.
      
      Fixes: cc8dbbb4 ("drm/radeon: add dpm support for CI dGPUs (v2)")
      Signed-off-by: default avatarTom Rix <trix@redhat.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      3dc9ed81
    • Boris Burkov's avatar
      btrfs: fix fatal extent_buffer readahead vs releasepage race · ffb059aa
      Boris Burkov authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit 6bf9cd2e upstream.
      
      Under somewhat convoluted conditions, it is possible to attempt to
      release an extent_buffer that is under io, which triggers a BUG_ON in
      btrfs_release_extent_buffer_pages.
      
      This relies on a few different factors. First, extent_buffer reads done
      as readahead for searching use WAIT_NONE, so they free the local extent
      buffer reference while the io is outstanding. However, they should still
      be protected by TREE_REF. However, if the system is doing signficant
      reclaim, and simultaneously heavily accessing the extent_buffers, it is
      possible for releasepage to race with two concurrent readahead attempts
      in a way that leaves TREE_REF unset when the readahead extent buffer is
      released.
      
      Essentially, if two tasks race to allocate a new extent_buffer, but the
      winner who attempts the first io is rebuffed by a page being locked
      (likely by the reclaim itself) then the loser will still go ahead with
      issuing the readahead. The loser's call to find_extent_buffer must also
      race with the reclaim task reading the extent_buffer's refcount as 1 in
      a way that allows the reclaim to re-clear the TREE_REF checked by
      find_extent_buffer.
      
      The following represents an example execution demonstrating the race:
      
                  CPU0                                                         CPU1                                           CPU2
      reada_for_search                                            reada_for_search
        readahead_tree_block                                        readahead_tree_block
          find_create_tree_block                                      find_create_tree_block
            alloc_extent_buffer                                         alloc_extent_buffer
                                                                        find_extent_buffer // not found
                                                                        allocates eb
                                                                        lock pages
                                                                        associate pages to eb
                                                                        insert eb into radix tree
                                                                        set TREE_REF, refs == 2
                                                                        unlock pages
                                                                    read_extent_buffer_pages // WAIT_NONE
                                                                      not uptodate (brand new eb)
                                                                                                                  lock_page
                                                                      if !trylock_page
                                                                        goto unlock_exit // not an error
                                                                    free_extent_buffer
                                                                      release_extent_buffer
                                                                        atomic_dec_and_test refs to 1
              find_extent_buffer // found
                                                                                                                  try_release_extent_buffer
                                                                                                                    take refs_lock
                                                                                                                    reads refs == 1; no io
                atomic_inc_not_zero refs to 2
                mark_buffer_accessed
                  check_buffer_tree_ref
                    // not STALE, won't take refs_lock
                    refs == 2; TREE_REF set // no action
          read_extent_buffer_pages // WAIT_NONE
                                                                                                                    clear TREE_REF
                                                                                                                    release_extent_buffer
                                                                                                                      atomic_dec_and_test refs to 1
                                                                                                                      unlock_page
            still not uptodate (CPU1 read failed on trylock_page)
            locks pages
            set io_pages > 0
            submit io
            return
          free_extent_buffer
            release_extent_buffer
              dec refs to 0
              delete from radix tree
              btrfs_release_extent_buffer_pages
                BUG_ON(io_pages > 0)!!!
      
      We observe this at a very low rate in production and were also able to
      reproduce it in a test environment by introducing some spurious delays
      and by introducing probabilistic trylock_page failures.
      
      To fix it, we apply check_tree_ref at a point where it could not
      possibly be unset by a competing task: after io_pages has been
      incremented. All the codepaths that clear TREE_REF check for io, so they
      would not be able to clear it after this point until the io is done.
      
      Stack trace, for reference:
      [1417839.424739] ------------[ cut here ]------------
      [1417839.435328] kernel BUG at fs/btrfs/extent_io.c:4841!
      [1417839.447024] invalid opcode: 0000 [#1] SMP
      [1417839.502972] RIP: 0010:btrfs_release_extent_buffer_pages+0x20/0x1f0
      [1417839.517008] Code: ed e9 ...
      [1417839.558895] RSP: 0018:ffffc90020bcf798 EFLAGS: 00010202
      [1417839.570816] RAX: 0000000000000002 RBX: ffff888102d6def0 RCX: 0000000000000028
      [1417839.586962] RDX: 0000000000000002 RSI: ffff8887f0296482 RDI: ffff888102d6def0
      [1417839.603108] RBP: ffff88885664a000 R08: 0000000000000046 R09: 0000000000000238
      [1417839.619255] R10: 0000000000000028 R11: ffff88885664af68 R12: 0000000000000000
      [1417839.635402] R13: 0000000000000000 R14: ffff88875f573ad0 R15: ffff888797aafd90
      [1417839.651549] FS:  00007f5a844fa700(0000) GS:ffff88885f680000(0000) knlGS:0000000000000000
      [1417839.669810] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [1417839.682887] CR2: 00007f7884541fe0 CR3: 000000049f609002 CR4: 00000000003606e0
      [1417839.699037] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [1417839.715187] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [1417839.731320] Call Trace:
      [1417839.737103]  release_extent_buffer+0x39/0x90
      [1417839.746913]  read_block_for_search.isra.38+0x2a3/0x370
      [1417839.758645]  btrfs_search_slot+0x260/0x9b0
      [1417839.768054]  btrfs_lookup_file_extent+0x4a/0x70
      [1417839.778427]  btrfs_get_extent+0x15f/0x830
      [1417839.787665]  ? submit_extent_page+0xc4/0x1c0
      [1417839.797474]  ? __do_readpage+0x299/0x7a0
      [1417839.806515]  __do_readpage+0x33b/0x7a0
      [1417839.815171]  ? btrfs_releasepage+0x70/0x70
      [1417839.824597]  extent_readpages+0x28f/0x400
      [1417839.833836]  read_pages+0x6a/0x1c0
      [1417839.841729]  ? startup_64+0x2/0x30
      [1417839.849624]  __do_page_cache_readahead+0x13c/0x1a0
      [1417839.860590]  filemap_fault+0x6c7/0x990
      [1417839.869252]  ? xas_load+0x8/0x80
      [1417839.876756]  ? xas_find+0x150/0x190
      [1417839.884839]  ? filemap_map_pages+0x295/0x3b0
      [1417839.894652]  __do_fault+0x32/0x110
      [1417839.902540]  __handle_mm_fault+0xacd/0x1000
      [1417839.912156]  handle_mm_fault+0xaa/0x1c0
      [1417839.921004]  __do_page_fault+0x242/0x4b0
      [1417839.930044]  ? page_fault+0x8/0x30
      [1417839.937933]  page_fault+0x1e/0x30
      [1417839.945631] RIP: 0033:0x33c4bae
      [1417839.952927] Code: Bad RIP value.
      [1417839.960411] RSP: 002b:00007f5a844f7350 EFLAGS: 00010206
      [1417839.972331] RAX: 000000000000006e RBX: 1614b3ff6a50398a RCX: 0000000000000000
      [1417839.988477] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
      [1417840.004626] RBP: 00007f5a844f7420 R08: 000000000000006e R09: 00007f5a94aeccb8
      [1417840.020784] R10: 00007f5a844f7350 R11: 0000000000000000 R12: 00007f5a94aecc79
      [1417840.036932] R13: 00007f5a94aecc78 R14: 00007f5a94aecc90 R15: 00007f5a94aecc40
      
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarBoris Burkov <boris@bur.io>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      ffb059aa
    • Greg Kroah-Hartman's avatar
      Revert "ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb" · c0762f3b
      Greg Kroah-Hartman authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      This reverts commit 90ecba9f1041f436ed2b35ba7a970c7cc5d0df23 which is
      commit 2bbcaaee upstream.
      
      It is being reverted upstream, just hasn't made it there yet and is
      causing lots of problems.
      Reported-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: Qiujun Huang <hqjagain@gmail.com>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      c0762f3b
    • Paolo Bonzini's avatar
      KVM: x86: bit 8 of non-leaf PDPEs is not reserved · 788dadab
      Paolo Bonzini authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit 5ecad245 upstream.
      
      Bit 8 would be the "global" bit, which does not quite make sense for non-leaf
      page table entries.  Intel ignores it; AMD ignores it in PDEs and PDPEs, but
      reserves it in PML4Es.
      
      Probably, earlier versions of the AMD manual documented it as reserved in PDPEs
      as well, and that behavior made it into KVM as well as kvm-unit-tests; fix it.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarNadav Amit <namit@vmware.com>
      Fixes: a0c0feb5 ("KVM: x86: reserve bit 8 of non-leaf PDPEs and PML4Es in 64-bit mode on AMD", 2014-09-03)
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      788dadab
    • Hector Martin's avatar
      ALSA: usb-audio: add quirk for MacroSilicon MS2109 · 4e5354d9
      Hector Martin authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit e337bf19 upstream.
      
      These devices claim to be 96kHz mono, but actually are 48kHz stereo with
      swapped channels and unaligned transfers.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHector Martin <marcan@marcan.st>
      Link: https://lore.kernel.org/r/20200702071433.237843-1-marcan@marcan.stSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      4e5354d9
    • Hui Wang's avatar
      ALSA: hda - let hs_mic be picked ahead of hp_mic · 2ed48fe1
      Hui Wang authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit 6a6ca788 upstream.
      
      We have a Dell AIO, there is neither internal speaker nor internal
      mic, only a multi-function audio jack on it.
      
      Users reported that after freshly installing the OS and plug
      a headset to the audio jack, the headset can't output sound. I
      reproduced this bug, at that moment, the Input Source is as below:
      Simple mixer control 'Input Source',0
        Capabilities: cenum
        Items: 'Headphone Mic' 'Headset Mic'
        Item0: 'Headphone Mic'
      
      That is because the patch_realtek will set this audio jack as mic_in
      mode if Input Source's value is hp_mic.
      
      If it is not fresh installing, this issue will not happen since the
      systemd will run alsactl restore -f /var/lib/alsa/asound.state, this
      will set the 'Input Source' according to history value.
      
      If there is internal speaker or internal mic, this issue will not
      happen since there is valid sink/source in the pulseaudio, the PA will
      set the 'Input Source' according to active_port.
      
      To fix this issue, change the parser function to let the hs_mic be
      stored ahead of hp_mic.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Link: https://lore.kernel.org/r/20200625083833.11264-1-hui.wang@canonical.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      2ed48fe1
    • xidongwang's avatar
      ALSA: opl3: fix infoleak in opl3 · 3ddd703a
      xidongwang authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      commit ad155712 upstream.
      
      The stack object “info” in snd_opl3_ioctl() has a leaking problem.
      It has 2 padding bytes which are not initialized and leaked via
      “copy_to_user”.
      Signed-off-by: default avatarxidongwang <wangxidong_97@163.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/1594006058-30362-1-git-send-email-wangxidong_97@163.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      3ddd703a
    • Wei Li's avatar
      arm64: kgdb: Fix single-step exception handling oops · d27bfad3
      Wei Li authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 8523c006 ]
      
      After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
      delay installing breakpoints, do single-step first), it won't work
      correctly, and it will enter kdb due to oops.
      
      It's because the reason gotten in kdb_stub() is not as expected, and it
      seems that the ex_vector for single-step should be 0, like what arch
      powerpc/sh/parisc has implemented.
      
      Before the patch:
      Entering kdb (current=0xffff8000119e2dc0, pid 0) on processor 0 due to Keyboard Entry
      [0]kdb> bp printk
      Instruction(i) BP #0 at 0xffff8000101486cc (printk)
          is enabled   addr at ffff8000101486cc, hardtype=0 installed=0
      
      [0]kdb> g
      
      / # echo h > /proc/sysrq-trigger
      
      Entering kdb (current=0xffff0000fa878040, pid 266) on processor 3 due to Breakpoint @ 0xffff8000101486cc
      [3]kdb> ss
      
      Entering kdb (current=0xffff0000fa878040, pid 266) on processor 3 Oops: (null)
      due to oops @ 0xffff800010082ab8
      CPU: 3 PID: 266 Comm: sh Not tainted 5.7.0-rc4-13839-gf0e5ad491718 #6
      Hardware name: linux,dummy-virt (DT)
      pstate: 00000085 (nzcv daIf -PAN -UAO)
      pc : el1_irq+0x78/0x180
      lr : __handle_sysrq+0x80/0x190
      sp : ffff800015003bf0
      x29: ffff800015003d20 x28: ffff0000fa878040
      x27: 0000000000000000 x26: ffff80001126b1f0
      x25: ffff800011b6a0d8 x24: 0000000000000000
      x23: 0000000080200005 x22: ffff8000101486cc
      x21: ffff800015003d30 x20: 0000ffffffffffff
      x19: ffff8000119f2000 x18: 0000000000000000
      x17: 0000000000000000 x16: 0000000000000000
      x15: 0000000000000000 x14: 0000000000000000
      x13: 0000000000000000 x12: 0000000000000000
      x11: 0000000000000000 x10: 0000000000000000
      x9 : 0000000000000000 x8 : ffff800015003e50
      x7 : 0000000000000002 x6 : 00000000380b9990
      x5 : ffff8000106e99e8 x4 : ffff0000fadd83c0
      x3 : 0000ffffffffffff x2 : ffff800011b6a0d8
      x1 : ffff800011b6a000 x0 : ffff80001130c9d8
      Call trace:
       el1_irq+0x78/0x180
       printk+0x0/0x84
       write_sysrq_trigger+0xb0/0x118
       proc_reg_write+0xb4/0xe0
       __vfs_write+0x18/0x40
       vfs_write+0xb0/0x1b8
       ksys_write+0x64/0xf0
       __arm64_sys_write+0x14/0x20
       el0_svc_common.constprop.2+0xb0/0x168
       do_el0_svc+0x20/0x98
       el0_sync_handler+0xec/0x1a8
       el0_sync+0x140/0x180
      
      [3]kdb>
      
      After the patch:
      Entering kdb (current=0xffff8000119e2dc0, pid 0) on processor 0 due to Keyboard Entry
      [0]kdb> bp printk
      Instruction(i) BP #0 at 0xffff8000101486cc (printk)
          is enabled   addr at ffff8000101486cc, hardtype=0 installed=0
      
      [0]kdb> g
      
      / # echo h > /proc/sysrq-trigger
      
      Entering kdb (current=0xffff0000fa852bc0, pid 268) on processor 0 due to Breakpoint @ 0xffff8000101486cc
      [0]kdb> g
      
      Entering kdb (current=0xffff0000fa852bc0, pid 268) on processor 0 due to Breakpoint @ 0xffff8000101486cc
      [0]kdb> ss
      
      Entering kdb (current=0xffff0000fa852bc0, pid 268) on processor 0 due to SS trap @ 0xffff800010082ab8
      [0]kdb>
      
      Fixes: 44679a4f ("arm64: KGDB: Add step debugging support")
      Signed-off-by: default avatarWei Li <liwei391@huawei.com>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20200509214159.19680-2-liwei391@huawei.comSigned-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      d27bfad3
    • Vinod Koul's avatar
      ALSA: compress: fix partial_drain completion state · b6a37be1
      Vinod Koul authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit f79a732a ]
      
      On partial_drain completion we should be in SNDRV_PCM_STATE_RUNNING
      state, so set that for partially draining streams in
      snd_compr_drain_notify() and use a flag for partially draining streams
      
      While at it, add locks for stream state change in
      snd_compr_drain_notify() as well.
      
      Fixes: f44f2a54 ("ALSA: compress: fix drain calls blocking other compress functions (v6)")
      Reviewed-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Tested-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Reviewed-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Tested-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Link: https://lore.kernel.org/r/20200629134737.105993-4-vkoul@kernel.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      b6a37be1
    • Andre Edich's avatar
      smsc95xx: avoid memory leak in smsc95xx_bind · ae613d60
      Andre Edich authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 3ed58f96 ]
      
      In a case where the ID_REV register read is failed, the memory for a
      private data structure has to be freed before returning error from the
      function smsc95xx_bind.
      
      Fixes: bbd9f9ee ("smsc95xx: add wol support for more frame types")
      Signed-off-by: default avatarAndre Edich <andre.edich@microchip.com>
      Signed-off-by: default avatarParthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      ae613d60
    • Andre Edich's avatar
      smsc95xx: check return value of smsc95xx_reset · 434aa2e9
      Andre Edich authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 7c8b1e85 ]
      
      The return value of the function smsc95xx_reset() must be checked
      to avoid returning false success from the function smsc95xx_bind().
      
      Fixes: 2f7ca802 ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
      Signed-off-by: default avatarAndre Edich <andre.edich@microchip.com>
      Signed-off-by: default avatarParthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      434aa2e9
    • Li Heng's avatar
      net: cxgb4: fix return error value in t4_prep_fw · a74da33f
      Li Heng authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 8a259e6b ]
      
      t4_prep_fw goto bye tag with positive return value when something
      bad happened and which can not free resource in adap_init0.
      so fix it to return negative value.
      
      Fixes: 16e47624 ("cxgb4: Add new scheme to update T4/T5 firmware")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarLi Heng <liheng40@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      a74da33f
    • Tomas Henzl's avatar
      scsi: mptscsih: Fix read sense data size · 1064d280
      Tomas Henzl authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit afe89f11 ]
      
      The sense data buffer in sense_buf_pool is allocated with size of
      MPT_SENSE_BUFFER_ALLOC(64) (multiplied by req_depth) while SNS_LEN(sc)(96)
      is used when reading the data.  That may lead to a read from unallocated
      area, sometimes from another (unallocated) page.  To fix this, limit the
      read size to MPT_SENSE_BUFFER_ALLOC.
      
      Link: https://lore.kernel.org/r/20200616150446.4840-1-thenzl@redhat.comCo-developed-by: default avatarStanislav Saner <ssaner@redhat.com>
      Signed-off-by: default avatarStanislav Saner <ssaner@redhat.com>
      Signed-off-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      1064d280
    • Zhenzhong Duan's avatar
      spi: spidev: fix a potential use-after-free in spidev_release() · b26a193b
      Zhenzhong Duan authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 06096cc6 ]
      
      If an spi device is unbounded from the driver before the release
      process, there will be an NULL pointer reference when it's
      referenced in spi_slave_abort().
      
      Fix it by checking it's already freed before reference.
      Signed-off-by: default avatarZhenzhong Duan <zhenzhong.duan@gmail.com>
      Link: https://lore.kernel.org/r/20200618032125.4650-2-zhenzhong.duan@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      b26a193b
    • Zhenzhong Duan's avatar
      spi: spidev: fix a race between spidev_release and spidev_remove · 8dc36822
      Zhenzhong Duan authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit abd42781 ]
      
      Imagine below scene, spidev is referenced after it's freed.
      
      spidev_release()                spidev_remove()
      ...
                                      spin_lock_irq(&spidev->spi_lock);
                                          spidev->spi = NULL;
                                      spin_unlock_irq(&spidev->spi_lock);
      mutex_lock(&device_list_lock);
      dofree = (spidev->spi == NULL);
      if (dofree)
          kfree(spidev);
      mutex_unlock(&device_list_lock);
                                      mutex_lock(&device_list_lock);
                                      list_del(&spidev->device_entry);
                                      device_destroy(spidev_class, spidev->devt);
                                      clear_bit(MINOR(spidev->devt), minors);
                                      if (spidev->users == 0)
                                          kfree(spidev);
                                      mutex_unlock(&device_list_lock);
      
      Fix it by resetting spidev->spi in device_list_lock's protection.
      Signed-off-by: default avatarZhenzhong Duan <zhenzhong.duan@gmail.com>
      Link: https://lore.kernel.org/r/20200618032125.4650-1-zhenzhong.duan@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      8dc36822
    • Christian Borntraeger's avatar
      KVM: s390: reduce number of IO pins to 1 · 7c1c061c
      Christian Borntraeger authored
      BugLink: https://bugs.launchpad.net/bugs/1888690
      
      [ Upstream commit 77491129 ]
      
      The current number of KVM_IRQCHIP_NUM_PINS results in an order 3
      allocation (32kb) for each guest start/restart. This can result in OOM
      killer activity even with free swap when the memory is fragmented
      enough:
      
      kernel: qemu-system-s39 invoked oom-killer: gfp_mask=0x440dc0(GFP_KERNEL_ACCOUNT|__GFP_COMP|__GFP_ZERO), order=3, oom_score_adj=0
      kernel: CPU: 1 PID: 357274 Comm: qemu-system-s39 Kdump: loaded Not tainted 5.4.0-29-generic #33-Ubuntu
      kernel: Hardware name: IBM 8562 T02 Z06 (LPAR)
      kernel: Call Trace:
      kernel: ([<00000001f848fe2a>] show_stack+0x7a/0xc0)
      kernel:  [<00000001f8d3437a>] dump_stack+0x8a/0xc0
      kernel:  [<00000001f8687032>] dump_header+0x62/0x258
      kernel:  [<00000001f8686122>] oom_kill_process+0x172/0x180
      kernel:  [<00000001f8686abe>] out_of_memory+0xee/0x580
      kernel:  [<00000001f86e66b8>] __alloc_pages_slowpath+0xd18/0xe90
      kernel:  [<00000001f86e6ad4>] __alloc_pages_nodemask+0x2a4/0x320
      kernel:  [<00000001f86b1ab4>] kmalloc_order+0x34/0xb0
      kernel:  [<00000001f86b1b62>] kmalloc_order_trace+0x32/0xe0
      kernel:  [<00000001f84bb806>] kvm_set_irq_routing+0xa6/0x2e0
      kernel:  [<00000001f84c99a4>] kvm_arch_vm_ioctl+0x544/0x9e0
      kernel:  [<00000001f84b8936>] kvm_vm_ioctl+0x396/0x760
      kernel:  [<00000001f875df66>] do_vfs_ioctl+0x376/0x690
      kernel:  [<00000001f875e304>] ksys_ioctl+0x84/0xb0
      kernel:  [<00000001f875e39a>] __s390x_sys_ioctl+0x2a/0x40
      kernel:  [<00000001f8d55424>] system_call+0xd8/0x2c8
      
      As far as I can tell s390x does not use the iopins as we bail our for
      anything other than KVM_IRQ_ROUTING_S390_ADAPTER and the chip/pin is
      only used for KVM_IRQ_ROUTING_IRQCHIP. So let us use a small number to
      reduce the memory footprint.
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Link: https://lore.kernel.org/r/20200617083620.5409-1-borntraeger@de.ibm.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      7c1c061c
    • Khalid Elmously's avatar
      UBUNTU: Start new release · 400935c6
      Khalid Elmously authored
      Ignore: yes
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      400935c6
  2. 20 Jul, 2020 3 commits
  3. 17 Jul, 2020 1 commit
    • Mauricio Faria de Oliveira's avatar
      bcache: check and adjust logical block size for backing devices · a277f856
      Mauricio Faria de Oliveira authored
      BugLink: https://bugs.launchpad.net/bugs/1867916
      
      It's possible for a block driver to set logical block size to
      a value greater than page size incorrectly; e.g. bcache takes
      the value from the superblock, set by the user w/ make-bcache.
      
      This causes a BUG/NULL pointer dereference in the path:
      
        __blkdev_get()
        -> set_init_blocksize() // set i_blkbits based on ...
           -> bdev_logical_block_size()
              -> queue_logical_block_size() // ... this value
        -> bdev_disk_changed()
           ...
           -> blkdev_readpage()
              -> block_read_full_page()
                 -> create_page_buffers() // size = 1 << i_blkbits
                    -> create_empty_buffers() // give size/take pointer
                       -> alloc_page_buffers() // return NULL
                       .. BUG!
      
      Because alloc_page_buffers() is called with size > PAGE_SIZE,
      thus it initializes head = NULL, skips the loop, return head;
      then create_empty_buffers() gets (and uses) the NULL pointer.
      
      This has been around longer than commit ad6bf88a ("block:
      fix an integer overflow in logical block size"); however, it
      increased the range of values that can trigger the issue.
      
      Previously only 8k/16k/32k (on x86/4k page size) would do it,
      as greater values overflow unsigned short to zero, and queue_
      logical_block_size() would then use the default of 512.
      
      Now the range with unsigned int is much larger, and users w/
      the 512k value, which happened to be zero'ed previously and
      work fine, started to hit this issue -- as the zero is gone,
      and queue_logical_block_size() does return 512k (>PAGE_SIZE.)
      
      Fix this by checking the bcache device's logical block size,
      and if it's greater than page size, fallback to the backing/
      cached device's logical page size.
      
      This doesn't affect cache devices as those are still checked
      for block/page size in read_super(); only the backing/cached
      devices are not.
      
      Apparently it's a regression from commit 2903381f ("bcache:
      Take data offset from the bdev superblock."), moving the check
      into BCACHE_SB_VERSION_CDEV only. Now that we have superblocks
      of backing devices out there with this larger value, we cannot
      refuse to load them (i.e., have a similar check in _BDEV.)
      
      Ideally perhaps bcache should use all values from the backing
      device (physical/logical/io_min block size)? But for now just
      fix the problematic case.
      
      Test-case:
      
          # IMG=/root/disk.img
          # dd if=/dev/zero of=$IMG bs=1 count=0 seek=1G
          # DEV=$(losetup --find --show $IMG)
          # make-bcache --bdev $DEV --block 8k
            < see dmesg >
      
      Before:
      
          # uname -r
          5.7.0-rc7
      
          [   55.944046] BUG: kernel NULL pointer dereference, address: 0000000000000000
          ...
          [   55.949742] CPU: 3 PID: 610 Comm: bcache-register Not tainted 5.7.0-rc7 #4
          ...
          [   55.952281] RIP: 0010:create_empty_buffers+0x1a/0x100
          ...
          [   55.966434] Call Trace:
          [   55.967021]  create_page_buffers+0x48/0x50
          [   55.967834]  block_read_full_page+0x49/0x380
          [   55.972181]  do_read_cache_page+0x494/0x610
          [   55.974780]  read_part_sector+0x2d/0xaa
          [   55.975558]  read_lba+0x10e/0x1e0
          [   55.977904]  efi_partition+0x120/0x5a6
          [   55.980227]  blk_add_partitions+0x161/0x390
          [   55.982177]  bdev_disk_changed+0x61/0xd0
          [   55.982961]  __blkdev_get+0x350/0x490
          [   55.983715]  __device_add_disk+0x318/0x480
          [   55.984539]  bch_cached_dev_run+0xc5/0x270
          [   55.986010]  register_bcache.cold+0x122/0x179
          [   55.987628]  kernfs_fop_write+0xbc/0x1a0
          [   55.988416]  vfs_write+0xb1/0x1a0
          [   55.989134]  ksys_write+0x5a/0xd0
          [   55.989825]  do_syscall_64+0x43/0x140
          [   55.990563]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
          [   55.991519] RIP: 0033:0x7f7d60ba3154
          ...
      
      After:
      
          # uname -r
          5.7.0.bcachelbspgsz
      
          [   31.672460] bcache: bcache_device_init() bcache0: sb/logical block size (8192) greater than page size (4096) falling back to device logical block size (512)
          [   31.675133] bcache: register_bdev() registered backing device loop0
      
          # grep ^ /sys/block/bcache0/queue/*_block_size
          /sys/block/bcache0/queue/logical_block_size:512
          /sys/block/bcache0/queue/physical_block_size:8192
      Reported-by: default avatarRyan Finnie <ryan@finnie.org>
      Reported-by: default avatarSebastian Marsching <sebastian@marsching.com>
      Signed-off-by: default avatarMauricio Faria de Oliveira <mfo@canonical.com>
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      (backported from commit dcacbc12)
      [mfo: backport: hunks 1/3/4: adjust bcache_device_init() signature
       and calls for the lack of parameter make_request_fn from upstream.
       hunk 1: adjust bcache_device_init() signature for 'unsigned (int)',
               and refresh one context line.
       hunk 2: change from blk_queue_flag_set/clear() to set/clear_bit().]
      Signed-off-by: default avatarMauricio Faria de Oliveira <mfo@canonical.com>
      Acked-by: default avatarAndrea Righi <andrea.righi@canonical.com>
      Acked-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarKelsey Skunberg <kelsey.skunberg@canonical.com>
      a277f856
  4. 14 Jul, 2020 7 commits