Skip to content
  1. Mar 02, 2022
    • Liang Zhang's avatar
      KVM: x86/mmu: make apf token non-zero to fix bug · 72fdfc75
      Liang Zhang authored
      commit 6f3c1fc5
      
       upstream.
      
      In current async pagefault logic, when a page is ready, KVM relies on
      kvm_arch_can_dequeue_async_page_present() to determine whether to deliver
      a READY event to the Guest. This function test token value of struct
      kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a
      READY event is finished by Guest. If value is zero meaning that a READY
      event is done, so the KVM can deliver another.
      But the kvm_arch_setup_async_pf() may produce a valid token with zero
      value, which is confused with previous mention and may lead the loss of
      this READY event.
      
      This bug may cause task blocked forever in Guest:
       INFO: task stress:7532 blocked for more than 1254 seconds.
             Not tainted 5.10.0 #16
       "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
       task:stress          state:D stack:    0 pid: 7532 ppid:  1409
       flags:0x00000080
       Call Trace:
        __schedule+0x1e7/0x650
        schedule+0x46/0xb0
        kvm_async_pf_task_wait_schedule+0xad/0xe0
        ? exit_to_user_mode_prepare+0x60/0x70
        __kvm_handle_async_pf+0x4f/0xb0
        ? asm_exc_page_fault+0x8/0x30
        exc_page_fault+0x6f/0x110
        ? asm_exc_page_fault+0x8/0x30
        asm_exc_page_fault+0x1e/0x30
       RIP: 0033:0x402d00
       RSP: 002b:00007ffd31912500 EFLAGS: 00010206
       RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0
       RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0
       RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086
       R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000
       R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000
      
      Signed-off-by: default avatarLiang Zhang <zhangliang5@huawei.com>
      Message-Id: <20220222031239.1076682-1-zhangliang5@huawei.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72fdfc75
    • Helge Deller's avatar
      parisc/unaligned: Fix ldw() and stw() unalignment handlers · 646b532f
      Helge Deller authored
      commit a9727983
      
       upstream.
      
      Fix 3 bugs:
      
      a) emulate_stw() doesn't return the error code value, so faulting
      instructions are not reported and aborted.
      
      b) Tell emulate_ldw() to handle fldw_l as floating point instruction
      
      c) Tell emulate_ldw() to handle ldw_m as integer instruction
      
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      646b532f
    • Helge Deller's avatar
      parisc/unaligned: Fix fldd and fstd unaligned handlers on 32-bit kernel · 397b5433
      Helge Deller authored
      commit dd2288f4
      
       upstream.
      
      Usually the kernel provides fixup routines to emulate the fldd and fstd
      floating-point instructions if they load or store 8-byte from/to a not
      natuarally aligned memory location.
      
      On a 32-bit kernel I noticed that those unaligned handlers didn't worked and
      instead the application got a SEGV.
      While checking the code I found two problems:
      
      First, the OPCODE_FLDD_L and OPCODE_FSTD_L cases were ifdef'ed out by the
      CONFIG_PA20 option, and as such those weren't built on a pure 32-bit kernel.
      This is now fixed by moving the CONFIG_PA20 #ifdef to prevent the compilation
      of OPCODE_LDD_L and OPCODE_FSTD_L only, and handling the fldd and fstd
      instructions.
      
      The second problem are two bugs in the 32-bit inline assembly code, where the
      wrong registers where used. The calculation of the natural alignment used %2
      (vall) instead of %3 (ior), and the first word was stored back to address %1
      (valh) instead of %3 (ior).
      
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      397b5433
    • Stefano Garzarella's avatar
      vhost/vsock: don't check owner in vhost_vsock_stop() while releasing · 698dc7d1
      Stefano Garzarella authored
      commit a58da53f upstream.
      
      vhost_vsock_stop() calls vhost_dev_check_owner() to check the device
      ownership. It expects current->mm to be valid.
      
      vhost_vsock_stop() is also called by vhost_vsock_dev_release() when
      the user has not done close(), so when we are in do_exit(). In this
      case current->mm is invalid and we're releasing the device, so we
      should clean it anyway.
      
      Let's check the owner only when vhost_vsock_stop() is called
      by an ioctl.
      
      When invoked from release we can not fail so we don't check return
      code of vhost_vsock_stop(). We need to stop vsock even if it's not
      the owner.
      
      Fixes: 433fc58e
      
       ("VSOCK: Introduce vhost_vsock.ko")
      Cc: stable@vger.kernel.org
      Reported-by: default avatar <syzbot+1e3ea63db39f2b4440e0@syzkaller.appspotmail.com>
      Reported-and-tested-by: default avatar <syzbot+3140b17cb44a7b174008@syzkaller.appspotmail.com>
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      698dc7d1
    • Siarhei Volkau's avatar
      clk: jz4725b: fix mmc0 clock gating · 84e303b4
      Siarhei Volkau authored
      commit 2f0754f2 upstream.
      
      The mmc0 clock gate bit was mistakenly assigned to "i2s" clock.
      You can find that the same bit is assigned to "mmc0" too.
      It leads to mmc0 hang for a long time after any sound activity
      also it  prevented PM_SLEEP to work properly.
      I guess it was introduced by copy-paste from jz4740 driver
      where it is really controls I2S clock gate.
      
      Fixes: 226dfa47
      
       ("clk: Add Ingenic jz4725b CGU driver")
      Signed-off-by: default avatarSiarhei Volkau <lis8215@gmail.com>
      Tested-by: default avatarSiarhei Volkau <lis8215@gmail.com>
      Reviewed-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20220205171849.687805-2-lis8215@gmail.com
      
      
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84e303b4
    • Su Yue's avatar
      btrfs: tree-checker: check item_size for dev_item · 72a5b018
      Su Yue authored
      commit ea1d1ca4
      
       upstream.
      
      Check item size before accessing the device item to avoid out of bound
      access, similar to inode_item check.
      
      Signed-off-by: default avatarSu Yue <l@damenly.su>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72a5b018
    • Su Yue's avatar
      btrfs: tree-checker: check item_size for inode_item · 5c967dd0
      Su Yue authored
      commit 0c982944 upstream.
      
      while mounting the crafted image, out-of-bounds access happens:
      
        [350.429619] UBSAN: array-index-out-of-bounds in fs/btrfs/struct-funcs.c:161:1
        [350.429636] index 1048096 is out of range for type 'page *[16]'
        [350.429650] CPU: 0 PID: 9 Comm: kworker/u8:1 Not tainted 5.16.0-rc4 #1
        [350.429652] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
        [350.429653] Workqueue: btrfs-endio-meta btrfs_work_helper [btrfs]
        [350.429772] Call Trace:
        [350.429774]  <TASK>
        [350.429776]  dump_stack_lvl+0x47/0x5c
        [350.429780]  ubsan_epilogue+0x5/0x50
        [350.429786]  __ubsan_handle_out_of_bounds+0x66/0x70
        [350.429791]  btrfs_get_16+0xfd/0x120 [btrfs]
        [350.429832]  check_leaf+0x754/0x1a40 [btrfs]
        [350.429874]  ? filemap_read+0x34a/0x390
        [350.429878]  ? load_balance+0x175/0xfc0
        [350.429881]  validate_extent_buffer+0x244/0x310 [btrfs]
        [350.429911]  btrfs_validate_metadata_buffer+0xf8/0x100 [btrfs]
        [350.429935]  end_bio_extent_readpage+0x3af/0x850 [btrfs]
        [350.429969]  ? newidle_balance+0x259/0x480
        [350.429972]  end_workqueue_fn+0x29/0x40 [btrfs]
        [350.429995]  btrfs_work_helper+0x71/0x330 [btrfs]
        [350.430030]  ? __schedule+0x2fb/0xa40
        [350.430033]  process_one_work+0x1f6/0x400
        [350.430035]  ? process_one_work+0x400/0x400
        [350.430036]  worker_thread+0x2d/0x3d0
        [350.430037]  ? process_one_work+0x400/0x400
        [350.430038]  kthread+0x165/0x190
        [350.430041]  ? set_kthread_struct+0x40/0x40
        [350.430043]  ret_from_fork+0x1f/0x30
        [350.430047]  </TASK>
        [350.430077] BTRFS warning (device loop0): bad eb member start: ptr 0xffe20f4e start 20975616 member offset 4293005178 size 2
      
      check_leaf() is checking the leaf:
      
        corrupt leaf: root=4 block=29396992 slot=1, bad key order, prev (16140901064495857664 1 0) current (1 204 12582912)
        leaf 29396992 items 6 free space 3565 generation 6 owner DEV_TREE
        leaf 29396992 flags 0x1(WRITTEN) backref revision 1
        fs uuid a62e00e8-e94e-4200-8217-12444de93c2e
        chunk uuid cecbd0f7-9ca0-441e-ae9f-f782f9732bd8
      	  item 0 key (16140901064495857664 INODE_ITEM 0) itemoff 3955 itemsize 40
      		  generation 0 transid 0 size 0 nbytes 17592186044416
      		  block group 0 mode 52667 links 33 uid 0 gid 2104132511 rdev 94223634821136
      		  sequence 100305 flags 0x2409000(none)
      		  atime 0.0 (1970-01-01 08:00:00)
      		  ctime 2973280098083405823.4294967295 (-269783007-01-01 21:37:03)
      		  mtime 18446744071572723616.4026825121 (1902-04-16 12:40:00)
      		  otime 9249929404488876031.4294967295 (622322949-04-16 04:25:58)
      	  item 1 key (1 DEV_EXTENT 12582912) itemoff 3907 itemsize 48
      		  dev extent chunk_tree 3
      		  chunk_objectid 256 chunk_offset 12582912 length 8388608
      		  chunk_tree_uuid cecbd0f7-9ca0-441e-ae9f-f782f9732bd8
      
      The corrupted leaf of device tree has an inode item. The leaf passed
      checksum and others checks in validate_extent_buffer until check_leaf_item().
      Because of the key type BTRFS_INODE_ITEM, check_inode_item() is called even we
      are in the device tree. Since the
      item offset + sizeof(struct btrfs_inode_item) > eb->len, out-of-bounds access
      is triggered.
      
      The item end vs leaf boundary check has been done before
      check_leaf_item(), so fix it by checking item size in check_inode_item()
      before access of the inode item in extent buffer.
      
      Other check functions except check_dev_item() in check_leaf_item()
      have their item size checks.
      The commit for check_dev_item() is followed.
      
      No regression observed during running fstests.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215299
      
      
      CC: stable@vger.kernel.org # 5.10+
      CC: Wenqing Liu <wenqingliu0120@gmail.com>
      Signed-off-by: default avatarSu Yue <l@damenly.su>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c967dd0
    • Zhang Qiao's avatar
      cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug · fcec42dd
      Zhang Qiao authored
      commit 05c7b7a9 upstream.
      
      As previously discussed(https://lkml.org/lkml/2022/1/20/51),
      cpuset_attach() is affected with similar cpu hotplug race,
      as follow scenario:
      
           cpuset_attach()				cpu hotplug
          ---------------------------            ----------------------
          down_write(cpuset_rwsem)
          guarantee_online_cpus() // (load cpus_attach)
      					sched_cpu_deactivate
      					  set_cpu_active()
      					  // will change cpu_active_mask
          set_cpus_allowed_ptr(cpus_attach)
            __set_cpus_allowed_ptr_locked()
             // (if the intersection of cpus_attach and
               cpu_active_mask is empty, will return -EINVAL)
          up_write(cpuset_rwsem)
      
      To avoid races such as described above, protect cpuset_attach() call
      with cpu_hotplug_lock.
      
      Fixes: be367d09
      
       ("cgroups: let ss->can_attach and ss->attach do whole threadgroups at a time")
      Cc: stable@vger.kernel.org # v2.6.32+
      Reported-by: default avatarZhao Gongyi <zhaogongyi@huawei.com>
      Signed-off-by: default avatarZhang Qiao <zhangqiao22@huawei.com>
      Acked-by: default avatarWaiman Long <longman@redhat.com>
      Reviewed-by: default avatarMichal Koutný <mkoutny@suse.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcec42dd
  2. Feb 23, 2022