1. 11 Jun, 2021 6 commits
  2. 10 Jun, 2021 11 commits
    • Eric W. Biederman's avatar
      coredump: Limit what can interrupt coredumps · 06af8679
      Eric W. Biederman authored
      Olivier Langlois has been struggling with coredumps being incompletely written in
      processes using io_uring.
      
      Olivier Langlois <olivier@trillion01.com> writes:
      > io_uring is a big user of task_work and any event that io_uring made a
      > task waiting for that occurs during the core dump generation will
      > generate a TIF_NOTIFY_SIGNAL.
      >
      > Here are the detailed steps of the problem:
      > 1. io_uring calls vfs_poll() to install a task to a file wait queue
      >    with io_async_wake() as the wakeup function cb from io_arm_poll_handler()
      > 2. wakeup function ends up calling task_work_add() with TWA_SIGNAL
      > 3. task_work_add() sets the TIF_NOTIFY_SIGNAL bit by calling
      >    set_notify_signal()
      
      The coredump code deliberately supports being interrupted by SIGKILL,
      and depends upon prepare_signal to filter out all other signals.   Now
      that signal_pending includes wake ups for TIF_NOTIFY_SIGNAL this hack
      in dump_emitted by the coredump code no longer works.
      
      Make the coredump code more robust by explicitly testing for all of
      the wakeup conditions the coredump code supports.  This prevents
      new wakeup conditions from breaking the coredump code, as well
      as fixing the current issue.
      
      The filesystem code that the coredump code uses already limits
      itself to only aborting on fatal_signal_pending.  So it should
      not develop surprising wake-up reasons either.
      
      v2: Don't remove the now unnecessary code in prepare_signal.
      
      Cc: stable@vger.kernel.org
      Fixes: 12db8b69 ("entry: Add support for TIF_NOTIFY_SIGNAL")
      Reported-by: default avatarOlivier Langlois <olivier@trillion01.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      06af8679
    • Linus Torvalds's avatar
      Merge branch 'for-5.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup · f09eacca
      Linus Torvalds authored
      Pull cgroup fix from Tejun Heo:
       "This is a high priority but low risk fix for a cgroup1 bug where
        rename(2) can change a cgroup's name to something which can break
        parsing of /proc/PID/cgroup"
      
      * 'for-5.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
        cgroup1: don't allow '\n' in renaming
      f09eacca
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma · 29a877d5
      Linus Torvalds authored
      Pull rdma fixes from Jason Gunthorpe:
       "A mixture of small bug fixes and a small security issue:
      
         - WARN_ON when IPoIB is automatically moved between namespaces
      
         - Long standing bug where mlx5 would use the wrong page for the
           doorbell recovery memory if fork is used
      
         - Security fix for mlx4 that disables the timestamp feature
      
         - Several crashers for mlx5
      
         - Plug a recent mlx5 memory leak for the sig_mr"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
        IB/mlx5: Fix initializing CQ fragments buffer
        RDMA/mlx5: Delete right entry from MR signature database
        RDMA: Verify port when creating flow rule
        RDMA/mlx5: Block FDB rules when not in switchdev mode
        RDMA/mlx4: Do not map the core_clock page to user space unless enabled
        RDMA/mlx5: Use different doorbell memory for different processes
        RDMA/ipoib: Fix warning caused by destroying non-initial netns
      29a877d5
    • Robert Marko's avatar
      hwmon: (tps23861) correct shunt LSB values · e13d1127
      Robert Marko authored
      Current shunt LSB values got reversed during in the
      original driver commit.
      
      So, correct the current shunt LSB values according to
      the datasheet.
      
      This caused reading slightly skewed current values.
      
      Fixes: fff7b8ab ("hwmon: add Texas Instruments TPS23861 driver")
      Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
      Link: https://lore.kernel.org/r/20210609220728.499879-3-robert.marko@sartura.hrSigned-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      e13d1127
    • Robert Marko's avatar
      hwmon: (tps23861) set current shunt value · b325d352
      Robert Marko authored
      TPS23861 has a configuration bit for setting of the
      current shunt value used on the board.
      Its bit 0 of the General Mask 1 register.
      
      According to the datasheet bit values are:
      0 for 255 mOhm (Default)
      1 for 250 mOhm
      
      So, configure the bit before registering the hwmon
      device according to the value passed in the DTS or
      default one if none is passed.
      
      This caused potentially reading slightly skewed values
      due to max current value being 1.02A when 250mOhm shunt
      is used instead of 1.0A when 255mOhm is used.
      
      Fixes: fff7b8ab ("hwmon: add Texas Instruments TPS23861 driver")
      Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
      Link: https://lore.kernel.org/r/20210609220728.499879-2-robert.marko@sartura.hrSigned-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      b325d352
    • Robert Marko's avatar
      hwmon: (tps23861) define regmap max register · fb8543fb
      Robert Marko authored
      Define the max register address the device supports.
      This allows reading the whole register space via
      regmap debugfs, without it only register 0x0 is visible.
      
      This was forgotten in the original driver commit.
      
      Fixes: fff7b8ab ("hwmon: add Texas Instruments TPS23861 driver")
      Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
      Link: https://lore.kernel.org/r/20210609220728.499879-1-robert.marko@sartura.hrSigned-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      fb8543fb
    • Takashi Iwai's avatar
      ALSA: seq: Fix race of snd_seq_timer_open() · 83e197a8
      Takashi Iwai authored
      The timer instance per queue is exclusive, and snd_seq_timer_open()
      should have managed the concurrent accesses.  It looks as if it's
      checking the already existing timer instance at the beginning, but
      it's not right, because there is no protection, hence any later
      concurrent call of snd_seq_timer_open() may override the timer
      instance easily.  This may result in UAF, as the leftover timer
      instance can keep running while the queue itself gets closed, as
      spotted by syzkaller recently.
      
      For avoiding the race, add a proper check at the assignment of
      tmr->timeri again, and return -EBUSY if it's been already registered.
      
      Reported-by: syzbot+ddc1260a83ed1cbf6fb5@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/000000000000dce34f05c42f110c@google.com
      Link: https://lore.kernel.org/r/20210610152059.24633-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      83e197a8
    • Alexander Kuznetsov's avatar
      cgroup1: don't allow '\n' in renaming · b7e24eb1
      Alexander Kuznetsov authored
      cgroup_mkdir() have restriction on newline usage in names:
      $ mkdir $'/sys/fs/cgroup/cpu/test\ntest2'
      mkdir: cannot create directory
      '/sys/fs/cgroup/cpu/test\ntest2': Invalid argument
      
      But in cgroup1_rename() such check is missed.
      This allows us to make /proc/<pid>/cgroup unparsable:
      $ mkdir /sys/fs/cgroup/cpu/test
      $ mv /sys/fs/cgroup/cpu/test $'/sys/fs/cgroup/cpu/test\ntest2'
      $ echo $$ > $'/sys/fs/cgroup/cpu/test\ntest2'
      $ cat /proc/self/cgroup
      11:pids:/
      10:freezer:/
      9:hugetlb:/
      8:cpuset:/
      7:blkio:/user.slice
      6:memory:/user.slice
      5:net_cls,net_prio:/
      4:perf_event:/
      3:devices:/user.slice
      2:cpu,cpuacct:/test
      test2
      1:name=systemd:/
      0::/
      Signed-off-by: default avatarAlexander Kuznetsov <wwfq@yandex-team.ru>
      Reported-by: default avatarAndrey Krasichkov <buglloc@yandex-team.ru>
      Acked-by: default avatarDmitry Yakunin <zeil@yandex-team.ru>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      b7e24eb1
    • Alaa Hleihel's avatar
      IB/mlx5: Fix initializing CQ fragments buffer · 2ba0aa2f
      Alaa Hleihel authored
      The function init_cq_frag_buf() can be called to initialize the current CQ
      fragments buffer cq->buf, or the temporary cq->resize_buf that is filled
      during CQ resize operation.
      
      However, the offending commit started to use function get_cqe() for
      getting the CQEs, the issue with this change is that get_cqe() always
      returns CQEs from cq->buf, which leads us to initialize the wrong buffer,
      and in case of enlarging the CQ we try to access elements beyond the size
      of the current cq->buf and eventually hit a kernel panic.
      
       [exception RIP: init_cq_frag_buf+103]
        [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]
        [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]
        [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]
        [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]
        [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]
        [ffff9f799ddcbec8] kthread at ffffffffa66c5da1
        [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd
      
      Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that
      takes the correct source buffer as a parameter.
      
      Fixes: 388ca8be ("IB/mlx5: Implement fragmented completion queue (CQ)")
      Link: https://lore.kernel.org/r/90a0e8c924093cfa50a482880ad7e7edb73dc19a.1623309971.git.leonro@nvidia.comSigned-off-by: default avatarAlaa Hleihel <alaa@nvidia.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      2ba0aa2f
    • Aharon Landau's avatar
      RDMA/mlx5: Delete right entry from MR signature database · 6466f03f
      Aharon Landau authored
      The value mr->sig is stored in the entry upon mr allocation, however, ibmr
      is wrongly entered here as "old", therefore, xa_cmpxchg() does not replace
      the entry with NULL, which leads to the following trace:
      
       WARNING: CPU: 28 PID: 2078 at drivers/infiniband/hw/mlx5/main.c:3643 mlx5_ib_stage_init_cleanup+0x4d/0x60 [mlx5_ib]
       Modules linked in: nvme_rdma nvme_fabrics nvme_core 8021q garp mrp bonding bridge stp llc rfkill rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_tad
       CPU: 28 PID: 2078 Comm: reboot Tainted: G               X --------- ---  5.13.0-0.rc2.19.el9.x86_64 #1
       Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.9.1 12/07/2018
       RIP: 0010:mlx5_ib_stage_init_cleanup+0x4d/0x60 [mlx5_ib]
       Code: 8d bb 70 1f 00 00 be 00 01 00 00 e8 9d 94 ce da 48 3d 00 01 00 00 75 02 5b c3 0f 0b 5b c3 0f 0b 48 83 bb b0 20 00 00 00 74 d5 <0f> 0b eb d1 4
       RSP: 0018:ffffa8db06d33c90 EFLAGS: 00010282
       RAX: 0000000000000000 RBX: ffff97f890a44000 RCX: ffff97f900ec0160
       RDX: 0000000000000000 RSI: 0000000080080001 RDI: ffff97f890a44000
       RBP: ffffffffc0c189b8 R08: 0000000000000001 R09: 0000000000000000
       R10: 0000000000000001 R11: 0000000000000300 R12: ffff97f890a44000
       R13: ffffffffc0c36030 R14: 00000000fee1dead R15: 0000000000000000
       FS:  00007f0d5a8a3b40(0000) GS:ffff98077fb80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000555acbf4f450 CR3: 00000002a6f56002 CR4: 00000000001706e0
       Call Trace:
        mlx5r_remove+0x39/0x60 [mlx5_ib]
        auxiliary_bus_remove+0x1b/0x30
        __device_release_driver+0x17a/0x230
        device_release_driver+0x24/0x30
        bus_remove_device+0xdb/0x140
        device_del+0x18b/0x3e0
        mlx5_detach_device+0x59/0x90 [mlx5_core]
        mlx5_unload_one+0x22/0x60 [mlx5_core]
        shutdown+0x31/0x3a [mlx5_core]
        pci_device_shutdown+0x34/0x60
        device_shutdown+0x15b/0x1c0
        __do_sys_reboot.cold+0x2f/0x5b
        ? vfs_writev+0xc7/0x140
        ? handle_mm_fault+0xc5/0x290
        ? do_writev+0x6b/0x110
        do_syscall_64+0x40/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Fixes: e6fb246c ("RDMA/mlx5: Consolidate MR destruction to mlx5_ib_dereg_mr()")
      Link: https://lore.kernel.org/r/f3f585ea0db59c2a78f94f65eedeafc5a2374993.1623309971.git.leonro@nvidia.comSigned-off-by: default avatarAharon Landau <aharonl@nvidia.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      6466f03f
    • Maor Gottlieb's avatar
      RDMA: Verify port when creating flow rule · 2adcb4c5
      Maor Gottlieb authored
      Validate port value provided by the user and with that remove no longer
      needed validation by the driver.  The missing check in the mlx5_ib driver
      could cause to the below oops.
      
      Call trace:
        _create_flow_rule+0x2d4/0xf28 [mlx5_ib]
        mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
        ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
        ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
        ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
        ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
        do_vfs_ioctl+0xd0/0xaf0
        ksys_ioctl+0x84/0xb4
        __arm64_sys_ioctl+0x28/0xc4
        el0_svc_common.constprop.3+0xa4/0x254
        el0_svc_handler+0x84/0xa0
        el0_svc+0x10/0x26c
       Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)
      
      Fixes: 436f2ad0 ("IB/core: Export ib_create/destroy_flow through uverbs")
      Link: https://lore.kernel.org/r/faad30dc5219a01727f47db3dc2f029d07c82c00.1623309971.git.leonro@nvidia.comReviewed-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarMaor Gottlieb <maorg@nvidia.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      2adcb4c5
  3. 09 Jun, 2021 11 commits
  4. 08 Jun, 2021 12 commits
    • Paolo Bonzini's avatar
      kvm: avoid speculation-based attacks from out-of-range memslot accesses · da27a83f
      Paolo Bonzini authored
      KVM's mechanism for accessing guest memory translates a guest physical
      address (gpa) to a host virtual address using the right-shifted gpa
      (also known as gfn) and a struct kvm_memory_slot.  The translation is
      performed in __gfn_to_hva_memslot using the following formula:
      
            hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE
      
      It is expected that gfn falls within the boundaries of the guest's
      physical memory.  However, a guest can access invalid physical addresses
      in such a way that the gfn is invalid.
      
      __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
      retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot
      does check that the gfn falls within the boundaries of the guest's
      physical memory or not, a CPU can speculate the result of the check and
      continue execution speculatively using an illegal gfn. The speculation
      can result in calculating an out-of-bounds hva.  If the resulting host
      virtual address is used to load another guest physical address, this
      is effectively a Spectre gadget consisting of two consecutive reads,
      the second of which is data dependent on the first.
      
      Right now it's not clear if there are any cases in which this is
      exploitable.  One interesting case was reported by the original author
      of this patch, and involves visiting guest page tables on x86.  Right
      now these are not vulnerable because the hva read goes through get_user(),
      which contains an LFENCE speculation barrier.  However, there are
      patches in progress for x86 uaccess.h to mask kernel addresses instead of
      using LFENCE; once these land, a guest could use speculation to read
      from the VMM's ring 3 address space.  Other architectures such as ARM
      already use the address masking method, and would be susceptible to
      this same kind of data-dependent access gadgets.  Therefore, this patch
      proactively protects from these attacks by masking out-of-bounds gfns
      in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.
      
      Sean Christopherson noted that this patch does not cover
      kvm_read_guest_offset_cached.  This however is limited to a few bytes
      past the end of the cache, and therefore it is unlikely to be useful in
      the context of building a chain of data dependent accesses.
      Reported-by: default avatarArtemiy Margaritov <artemiy.margaritov@gmail.com>
      Co-developed-by: default avatarArtemiy Margaritov <artemiy.margaritov@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      da27a83f
    • Lai Jiangshan's avatar
      KVM: x86: Unload MMU on guest TLB flush if TDP disabled to force MMU sync · b53e84ee
      Lai Jiangshan authored
      When using shadow paging, unload the guest MMU when emulating a guest TLB
      flush to ensure all roots are synchronized.  From the guest's perspective,
      flushing the TLB ensures any and all modifications to its PTEs will be
      recognized by the CPU.
      
      Note, unloading the MMU is overkill, but is done to mirror KVM's existing
      handling of INVPCID(all) and ensure the bug is squashed.  Future cleanup
      can be done to more precisely synchronize roots when servicing a guest
      TLB flush.
      
      If TDP is enabled, synchronizing the MMU is unnecessary even if nested
      TDP is in play, as a "legacy" TLB flush from L1 does not invalidate L1's
      TDP mappings.  For EPT, an explicit INVEPT is required to invalidate
      guest-physical mappings; for NPT, guest mappings are always tagged with
      an ASID and thus can only be invalidated via the VMCB's ASID control.
      
      This bug has existed since the introduction of KVM_VCPU_FLUSH_TLB.
      It was only recently exposed after Linux guests stopped flushing the
      local CPU's TLB prior to flushing remote TLBs (see commit 4ce94eab,
      "x86/mm/tlb: Flush remote and local TLBs concurrently"), but is also
      visible in Windows 10 guests.
      Tested-by: default avatarMaxim Levitsky <mlevitsk@redhat.com>
      Reviewed-by: default avatarMaxim Levitsky <mlevitsk@redhat.com>
      Fixes: f38a7b75 ("KVM: X86: support paravirtualized help for TLB shootdowns")
      Signed-off-by: default avatarLai Jiangshan <laijs@linux.alibaba.com>
      [sean: massaged comment and changelog]
      Message-Id: <20210531172256.2908-1-jiangshanlai@gmail.com>
      Signed-off-by: default avatarSean Christopherson <seanjc@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b53e84ee
    • Mark Bloch's avatar
      RDMA/mlx5: Block FDB rules when not in switchdev mode · edc0b0bc
      Mark Bloch authored
      Allow creating FDB steering rules only when in switchdev mode.
      
      The only software model where a userspace application can manipulate
      FDB entries is when it manages the eswitch. This is only possible in
      switchdev mode where we expose a single RDMA device with representors
      for all the vports that are connected to the eswitch.
      
      Fixes: 52438be4 ("RDMA/mlx5: Allow inserting a steering rule to the FDB")
      Link: https://lore.kernel.org/r/e928ae7c58d07f104716a2a8d730963d1bd01204.1623052923.git.leonro@nvidia.comReviewed-by: default avatarMaor Gottlieb <maorg@nvidia.com>
      Signed-off-by: default avatarMark Bloch <mbloch@nvidia.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      edc0b0bc
    • Sean Christopherson's avatar
      KVM: x86: Ensure liveliness of nested VM-Enter fail tracepoint message · f31500b0
      Sean Christopherson authored
      Use the __string() machinery provided by the tracing subystem to make a
      copy of the string literals consumed by the "nested VM-Enter failed"
      tracepoint.  A complete copy is necessary to ensure that the tracepoint
      can't outlive the data/memory it consumes and deference stale memory.
      
      Because the tracepoint itself is defined by kvm, if kvm-intel and/or
      kvm-amd are built as modules, the memory holding the string literals
      defined by the vendor modules will be freed when the module is unloaded,
      whereas the tracepoint and its data in the ring buffer will live until
      kvm is unloaded (or "indefinitely" if kvm is built-in).
      
      This bug has existed since the tracepoint was added, but was recently
      exposed by a new check in tracing to detect exactly this type of bug.
      
        fmt: '%s%s
        ' current_buffer: ' vmx_dirty_log_t-140127  [003] ....  kvm_nested_vmenter_failed: '
        WARNING: CPU: 3 PID: 140134 at kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0
        CPU: 3 PID: 140134 Comm: less Not tainted 5.13.0-rc1-ce2e73ce600a-req #184
        Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014
        RIP: 0010:trace_check_vprintf+0x3be/0x3e0
        Code: <0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20
        RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282
        RAX: 0000000000000000 RBX: ffffa895cc37bd08 RCX: 0000000000000027
        RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8
        RBP: ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8
        R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffc0a041d4
        R13: ffffffffc0f4dba8 R14: 0000000000000000 R15: ffff976409f2c000
        FS:  00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0
        Call Trace:
         trace_event_printf+0x5e/0x80
         trace_raw_output_kvm_nested_vmenter_failed+0x3a/0x60 [kvm]
         print_trace_line+0x1dd/0x4e0
         s_show+0x45/0x150
         seq_read_iter+0x2d5/0x4c0
         seq_read+0x106/0x150
         vfs_read+0x98/0x180
         ksys_read+0x5f/0xe0
         do_syscall_64+0x40/0xb0
         entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Fixes: 380e0055 ("KVM: nVMX: trace nested VM-Enter failures detected by H/W")
      Signed-off-by: default avatarSean Christopherson <seanjc@google.com>
      Reviewed-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Message-Id: <20210607175748.674002-1-seanjc@google.com>
      f31500b0
    • Linus Torvalds's avatar
      Merge tag 'for-linus-5.13b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip · 368094df
      Linus Torvalds authored
      Pull xen fix from Juergen Gross:
       "A single patch fixing a Xen related security bug: a malicious guest
        might be able to trigger a 'use after free' issue in the xen-netback
        driver"
      
      * tag 'for-linus-5.13b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
        xen-netback: take a reference to the RX task thread
      368094df
    • Zhenzhong Duan's avatar
      selftests: kvm: Add support for customized slot0 memory size · f53b16ad
      Zhenzhong Duan authored
      Until commit 39fe2fc9 ("selftests: kvm: make allocation of extra
      memory take effect", 2021-05-27), parameter extra_mem_pages was used
      only to calculate the page table size for all the memory chunks,
      because real memory allocation happened with calls of
      vm_userspace_mem_region_add() after vm_create_default().
      
      Commit 39fe2fc9 however changed the meaning of extra_mem_pages to
      the size of memory slot 0.  This makes the memory allocation more
      flexible, but makes it harder to account for the number of
      pages needed for the page tables.  For example, memslot_perf_test
      has a small amount of memory in slot 0 but a lot in other slots,
      and adding that memory twice (both in slot 0 and with later
      calls to vm_userspace_mem_region_add()) causes an error that
      was fixed in commit 000ac429 ("selftests: kvm: fix overlapping
      addresses in memslot_perf_test", 2021-05-29)
      
      Since both uses are sensible, add a new parameter slot0_mem_pages
      to vm_create_with_vcpus() and some comments to clarify the meaning of
      slot0_mem_pages and extra_mem_pages.  With this change,
      memslot_perf_test can go back to passing the number of memory
      pages as extra_mem_pages.
      Signed-off-by: default avatarZhenzhong Duan <zhenzhong.duan@intel.com>
      Message-Id: <20210608233816.423958-4-zhenzhong.duan@intel.com>
      [Squashed in a single patch and rewrote the commit message. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f53b16ad
    • Linus Torvalds's avatar
      Merge tag 'orphans-v5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux · 374aeb91
      Linus Torvalds authored
      Pull orphan section fixes from Kees Cook:
       "These two corner case fixes have been in -next for about a week:
      
         - Avoid orphan section in ARM cpuidle (Arnd Bergmann)
      
         - Avoid orphan section with !SMP (Nathan Chancellor)"
      
      * tag 'orphans-v5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        vmlinux.lds.h: Avoid orphan section with !SMP
        ARM: cpuidle: Avoid orphan section warning
      374aeb91
    • Kees Cook's avatar
      proc: Track /proc/$pid/attr/ opener mm_struct · 591a22c1
      Kees Cook authored
      Commit bfb819ea ("proc: Check /proc/$pid/attr/ writes against file opener")
      tried to make sure that there could not be a confusion between the opener of
      a /proc/$pid/attr/ file and the writer. It used struct cred to make sure
      the privileges didn't change. However, there were existing cases where a more
      privileged thread was passing the opened fd to a differently privileged thread
      (during container setup). Instead, use mm_struct to track whether the opener
      and writer are still the same process. (This is what several other proc files
      already do, though for different reasons.)
      Reported-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Reported-by: default avatarAndrea Righi <andrea.righi@canonical.com>
      Tested-by: default avatarAndrea Righi <andrea.righi@canonical.com>
      Fixes: bfb819ea ("proc: Check /proc/$pid/attr/ writes against file opener")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      591a22c1
    • Christian Borntraeger's avatar
      KVM: selftests: introduce P47V64 for s390x · 1bc603af
      Christian Borntraeger authored
      s390x can have up to 47bits of physical guest and 64bits of virtual
      address  bits. Add a new address mode to avoid errors of testcases
      going beyond 47bits.
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Message-Id: <20210608123954.10991-1-borntraeger@de.ibm.com>
      Fixes: ef4c9f4f ("KVM: selftests: Fix 32-bit truncation of vm_get_max_gfn()")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarDavid Matlack <dmatlack@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1bc603af
    • Lai Jiangshan's avatar
      KVM: x86: Ensure PV TLB flush tracepoint reflects KVM behavior · af3511ff
      Lai Jiangshan authored
      In record_steal_time(), st->preempted is read twice, and
      trace_kvm_pv_tlb_flush() might output result inconsistent if
      kvm_vcpu_flush_tlb_guest() see a different st->preempted later.
      
      It is a very trivial problem and hardly has actual harm and can be
      avoided by reseting and reading st->preempted in atomic way via xchg().
      Signed-off-by: default avatarLai Jiangshan <laijs@linux.alibaba.com>
      
      Message-Id: <20210531174628.10265-1-jiangshanlai@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      af3511ff
    • Linus Torvalds's avatar
      Merge tag 'spi-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi · 4c8684fe
      Linus Torvalds authored
      Pull spi fixes from Mark Brown:
       "A small set of SPI fixes that have come up since the merge window, all
        fairly small fixes for rare cases"
      
      * tag 'spi-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
        spi: stm32-qspi: Always wait BUSY bit to be cleared in stm32_qspi_wait_cmd()
        spi: spi-zynq-qspi: Fix some wrong goto jumps & missing error code
        spi: Cleanup on failure of initial setup
        spi: bcm2835: Fix out-of-bounds access with more than 4 slaves
      4c8684fe
    • Linus Torvalds's avatar
      Merge tag 'regulator-fix-v5.13-rc4' of... · 9b1111fa
      Linus Torvalds authored
      Merge tag 'regulator-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
      
      Pull regulator fixes from Mark Brown:
       "A collection of fixes for the regulator API that have come up since
        the merge window, including a big batch of fixes from Axel Lin's usual
        careful and detailed review.
      
        The one stand out fix here is Dmitry Baryshkov's fix for an issue
        where we fail to power on the parents of always on regulators during
        system startup if they weren't already powered on"
      
      * tag 'regulator-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (21 commits)
        regulator: rt4801: Fix NULL pointer dereference if priv->enable_gpios is NULL
        regulator: hi6421v600: Fix .vsel_mask setting
        regulator: bd718x7: Fix the BUCK7 voltage setting on BD71837
        regulator: atc260x: Fix n_voltages and min_sel for pickable linear ranges
        regulator: rtmv20: Fix to make regcache value first reading back from HW
        regulator: mt6315: Fix function prototype for mt6315_map_mode
        regulator: rtmv20: Add Richtek to Kconfig text
        regulator: rtmv20: Fix .set_current_limit/.get_current_limit callbacks
        regulator: hisilicon: use the correct HiSilicon copyright
        regulator: bd71828: Fix .n_voltages settings
        regulator: bd70528: Fix off-by-one for buck123 .n_voltages setting
        regulator: max77620: Silence deferred probe error
        regulator: max77620: Use device_set_of_node_from_dev()
        regulator: scmi: Fix off-by-one for linear regulators .n_voltages setting
        regulator: core: resolve supply for boot-on/always-on regulators
        regulator: fixed: Ensure enable_counter is correct if reg_domain_disable fails
        regulator: Check ramp_delay_table for regulator_set_ramp_delay_regmap
        regulator: fan53880: Fix missing n_voltages setting
        regulator: da9121: Return REGULATOR_MODE_INVALID for invalid mode
        regulator: fan53555: fix TCS4525 voltage calulation
        ...
      9b1111fa