Skip to content
Snippets Groups Projects
  1. Sep 07, 2022
    • Maximilian Luz's avatar
      ACPICA: Fix exception code class checks · 29594958
      Maximilian Luz authored
      mainline inclusion
      from mainline-v5.12-rc1
      commit 3dfaea3811f8b6a89a347e8da9ab862cdf3e30fe
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5LBE7
      CVE: NA
      
      --------------------------------
      
      ACPICA commit 1a3a549286ea9db07d7ec700e7a70dd8bcc4354e
      
      The macros to classify different AML exception codes are broken. For
      instance,
      
        ACPI_ENV_EXCEPTION(Status)
      
      will always evaluate to zero due to
      
        #define AE_CODE_ENVIRONMENTAL      0x0000
        #define ACPI_ENV_EXCEPTION(Status) (Status & AE_CODE_ENVIRONMENTAL)
      
      Similarly, ACPI_AML_EXCEPTION(Status) will evaluate to a non-zero
      value for error codes of type AE_CODE_PROGRAMMER, AE_CODE_ACPI_TABLES,
      as well as AE_CODE_AML, and not just AE_CODE_AML as the name suggests.
      
      This commit fixes those checks.
      
      Fixes: d46b6537 ("ACPICA: AML Parser: ignore all exceptions resulting from incorrect AML during table load")
      Link: https://github.com/acpica/acpica/commit/1a3a5492
      
      
      Signed-off-by: default avatarMaximilian Luz <luzmaximilian@gmail.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarErik Kaneda <erik.kaneda@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      29594958
    • Qinglang Miao's avatar
      ACPI: configfs: add missing check after configfs_register_default_group() · 4a2289d6
      Qinglang Miao authored
      mainline inclusion
      from mainline-v5.12-rc1
      commit 67e40054de86aae520ddc2a072d7f6951812a14f
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5LBE7
      
      
      CVE: NA
      
      --------------------------------
      
      A list_add corruption is reported by Hulk Robot like this:
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      
      ==============
      list_add corruption.
      Call Trace:
      link_obj+0xc0/0x1c0
      link_group+0x21/0x140
      configfs_register_subsystem+0xdb/0x380
      acpi_configfs_init+0x25/0x1000 [acpi_configfs]
      do_one_initcall+0x149/0x820
      do_init_module+0x1ef/0x720
      load_module+0x35c8/0x4380
      __do_sys_finit_module+0x10d/0x1a0
      do_syscall_64+0x34/0x80
      
      It's because of the missing check after configfs_register_default_group,
      where configfs_unregister_subsystem should be called once failure.
      
      Fixes: 612bd01f ("ACPI: add support for loading SSDTs via configfs")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Suggested-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarQinglang Miao <miaoqinglang@huawei.com>
      Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      4a2289d6
    • Mark Langsdorf's avatar
      ACPI: custom_method: fix potential use-after-free issue · 75e3fec1
      Mark Langsdorf authored
      mainline inclusion
      from mainline-v5.13-rc1
      commit e483bb9a991bdae29a0caa4b3a6d002c968f94aa
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5LBE7
      
      
      CVE: NA
      
      --------------------------------
      
      In cm_write(), buf is always freed when reaching the end of the
      function.  If the requested count is less than table.length, the
      allocated buffer will be freed but subsequent calls to cm_write() will
      still try to access it.
      
      Remove the unconditional kfree(buf) at the end of the function and
      set the buf to NULL in the -EINVAL error path to match the rest of
      function.
      
      Fixes: 03d1571d ("ACPI: custom_method: fix memory leaks")
      Signed-off-by: default avatarMark Langsdorf <mlangsdo@redhat.com>
      Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      75e3fec1
    • Mark Langsdorf's avatar
      ACPI: custom_method: fix a possible memory leak · 98ad224d
      Mark Langsdorf authored
      mainline inclusion
      from mainline-v5.13-rc1
      commit 1cfd8956437f842836e8a066b40d1ec2fc01f13e
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5LBE7
      
      
      CVE: NA
      
      --------------------------------
      
      In cm_write(), if the 'buf' is allocated memory but not fully consumed,
      it is possible to reallocate the buffer without freeing it by passing
      '*ppos' as 0 on a subsequent call.
      
      Add an explicit kfree() before kzalloc() to prevent the possible memory
      leak.
      
      Fixes: 526b4af4 ("ACPI: Split out custom_method functionality into an own driver")
      Signed-off-by: default avatarMark Langsdorf <mlangsdo@redhat.com>
      Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      98ad224d
    • Jiasheng Jiang's avatar
      ACPI: APD: Check for NULL pointer after calling devm_ioremap() · 0c62d310
      Jiasheng Jiang authored
      mainline inclusion
      from mainline-v5.17-rc1
      commit 2cea3ec5b0099d0e9dd6752aa86e08bce38d6b32
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5LBE7
      
      
      CVE: NA
      
      --------------------------------
      
      Because devres_alloc() may fail, devm_ioremap() may return NULL.
      
      Then, 'clk_data->base' will be assigned to clkdev->data->base in
      platform_device_register_data().
      
      The PTR_ERR_OR_ZERO() check on clk_data does not cover 'base', so
      it is better to add an explicit check against NULL after updating
      it.
      
      Fixes: 3f4ba94e ("ACPI: APD: Add AMD misc clock handler support")
      Signed-off-by: default avatarJiasheng Jiang <jiasheng@iscas.ac.cn>
      [ rjw: Changelog rewrite ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      0c62d310
    • Tuan Phan's avatar
      ACPI/IORT: Fix PMCG node single ID mapping handling · 230917b0
      Tuan Phan authored
      mainline inclusion
      from mainline-v5.8-rc1
      commit 50c8ab8d
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5LBE7
      
      
      CVE: NA
      
      --------------------------------
      
      An IORT PMCG node can have no ID mapping if its overflow interrupt is
      wire based therefore the code that parses the PMCG node can not assume
      the node will always have a single mapping present at index 0.
      
      Fix iort_get_id_mapping_index() by checking for an overflow interrupt
      and mapping count.
      
      Fixes: 24e51604 ("ACPI/IORT: Add support for PMCG")
      
      Signed-off-by: default avatarTuan Phan <tuanphan@os.amperecomputing.com>
      Reviewed-by: default avatarHanjun Guo <guoahanjun@huawei.com>
      Acked-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Link: https://lore.kernel.org/r/1589994787-28637-1-git-send-email-tuanphan@os.amperecomputing.com
      
      
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      230917b0
    • Robin Murphy's avatar
      ACPI/IORT: Check node revision for PMCG resources · 58f57636
      Robin Murphy authored
      mainline inclusion
      from mainline-v5.17-rc4
      commit da5fb9e1ad3fbf632dce735f1bdad257ca528499
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5LBE7
      
      
      CVE: NA
      
      --------------------------------
      
      The original version of the IORT PMCG definition had an oversight
      wherein there was no way to describe the second register page for an
      implementation using the recommended RELOC_CTRS feature. Although the
      spec was fixed, and the final patches merged to ACPICA and Linux written
      against the new version, it seems that some old firmware based on the
      original revision has survived and turned up in the wild.
      
      Add a check for the original PMCG definition, and avoid filling in the
      second memory resource with nonsense if so. Otherwise it is likely that
      something horrible will happen when the PMCG driver attempts to probe.
      
      Reported-by: default avatarMichael Petlan <mpetlan@redhat.com>
      Fixes: 24e51604 ("ACPI/IORT: Add support for PMCG")
      Cc: <stable@vger.kernel.org> # 5.2.x
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Link: https://lore.kernel.org/r/75628ae41c257fb73588f7bf1c4459160e04be2b.1643916258.git.robin.murphy@arm.com
      
      
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      58f57636
    • Kuniyuki Iwashima's avatar
      kprobes: don't call disarm_kprobe() for disabled kprobes · 80c40ab1
      Kuniyuki Iwashima authored
      mainline inclusion
      from mainline-v6.0-rc3
      commit 9c80e79906b4ca440d09e7f116609262bb747909
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q4Z0
      CVE: NA
      
      --------------------------------
      
      The assumption in __disable_kprobe() is wrong, and it could try to disarm
      an already disarmed kprobe and fire the WARN_ONCE() below. [0]  We can
      easily reproduce this issue.
      
      1. Write 0 to /sys/kernel/debug/kprobes/enabled.
      
        # echo 0 > /sys/kernel/debug/kprobes/enabled
      
      2. Run execsnoop.  At this time, one kprobe is disabled.
      
        # /usr/share/bcc/tools/execsnoop &
        [1] 2460
        PCOMM            PID    PPID   RET ARGS
      
        # cat /sys/kernel/debug/kprobes/list
        ffffffff91345650  r  __x64_sys_execve+0x0    [FTRACE]
        ffffffff91345650  k  __x64_sys_execve+0x0    [DISABLED][FTRACE]
      
      3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes
         kprobes_all_disarmed to false but does not arm the disabled kprobe.
      
        # echo 1 > /sys/kernel/debug/kprobes/enabled
      
        # cat /sys/kernel/debug/kprobes/list
        ffffffff91345650  r  __x64_sys_execve+0x0    [FTRACE]
        ffffffff91345650  k  __x64_sys_execve+0x0    [DISABLED][FTRACE]
      
      4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the
         disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().
      
        # fg
        /usr/share/bcc/tools/execsnoop
        ^C
      
      Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses
      some cleanups and leaves the aggregated kprobe in the hash table.  Then,
      __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an
      infinite loop like this.
      
        aggregated kprobe.list -> kprobe.list -.
                                           ^    |
                                           '.__.'
      
      In this situation, these commands fall into the infinite loop and result
      in RCU stall or soft lockup.
      
        cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the
                                             infinite loop with RCU.
      
        /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex,
                                         and __get_valid_kprobe() is stuck in
      				   the loop.
      
      To avoid the issue, make sure we don't call disarm_kprobe() for disabled
      kprobes.
      
      [0]
      Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2)
      WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)
      Modules linked in: ena
      CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28
      Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017
      RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)
      Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94
      RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001
      RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff
      RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff
      R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40
      R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000
      FS:  00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
      <TASK>
       __disable_kprobe (kernel/kprobes.c:1716)
       disable_kprobe (kernel/kprobes.c:2392)
       __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340)
       disable_trace_kprobe (kernel/trace/trace_kprobe.c:429)
       perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168)
       perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295)
       _free_event (kernel/events/core.c:4971)
       perf_event_release_kernel (kernel/events/core.c:5176)
       perf_release (kernel/events/core.c:5186)
       __fput (fs/file_table.c:321)
       task_work_run (./include/linux/sched.h:2056 (discriminator 1) kernel/task_work.c:179 (discriminator 1))
       exit_to_user_mode_prepare (./include/linux/resume_user_mode.h:49 kernel/entry/common.c:169 kernel/entry/common.c:201)
       syscall_exit_to_user_mode (./arch/x86/include/asm/jump_label.h:55 ./arch/x86/include/asm/nospec-branch.h:384 ./arch/x86/include/asm/entry-common.h:94 kernel/entry/common.c:133 kernel/entry/common.c:296)
       do_syscall_64 (arch/x86/entry/common.c:87)
       entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
      RIP: 0033:0x7fe7ff210654
      Code: 15 79 89 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb be 0f 1f 00 8b 05 9a cd 20 00 48 63 ff 85 c0 75 11 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3a f3 c3 48 83 ec 18 48 89 7c 24 08 e8 34 fc
      RSP: 002b:00007ffdbd1d3538 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
      RAX: 0000000000000000 RBX: 0000000000000008 RCX: 00007fe7ff210654
      RDX: 0000000000000000 RSI: 0000000000002401 RDI: 0000000000000008
      RBP: 0000000000000000 R08: 94ae31d6fda838a4 R0900007fe8001c9d30
      R10: 00007ffdbd1d34b0 R11: 0000000000000246 R12: 00007ffdbd1d3600
      R13: 0000000000000000 R14: fffffffffffffffc R15: 00007ffdbd1d3560
      </TASK>
      
      Link: https://lkml.kernel.org/r/20220813020509.90805-1-kuniyu@amazon.com
      
      
      Fixes: 69d54b91 ("kprobes: makes kprobes/enabled works correctly for optimized kprobes.")
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Reported-by: default avatarAyushman Dutta <ayudutta@amazon.com>
      Cc: "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Kuniyuki Iwashima <kuniyu@amazon.com>
      Cc: Kuniyuki Iwashima <kuni1840@gmail.com>
      Cc: Ayushman Dutta <ayudutta@amazon.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      
      Signed-off-by: default avatarChen Zhongjin <chenzhongjin@huawei.com>
      Reviewed-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      80c40ab1
    • Chen Zhongjin's avatar
      x86/unwind/orc: Unwind ftrace trampolines with correct ORC entry · 70b4c071
      Chen Zhongjin authored
      mainline inclusion
      from mainline-v6.0-rc3
      commit fc2e426b1161761561624ebd43ce8c8d2fa058da
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q4RA
      
      
      CVE: NA
      
      --------------------------------
      
      When meeting ftrace trampolines in ORC unwinding, unwinder uses address
      of ftrace_{regs_}call address to find the ORC entry, which gets next frame at
      sp+176.
      
      If there is an IRQ hitting at sub $0xa8,%rsp, the next frame should be
      sp+8 instead of 176. It makes unwinder skip correct frame and throw
      warnings such as "wrong direction" or "can't access registers", etc,
      depending on the content of the incorrect frame address.
      
      By adding the base address ftrace_{regs_}caller with the offset
      *ip - ops->trampoline*, we can get the correct address to find the ORC entry.
      
      Also change "caller" to "tramp_addr" to make variable name conform to
      its content.
      
      [ mingo: Clarified the changelog a bit. ]
      
      Fixes: 6be7fa3c ("ftrace, orc, x86: Handle ftrace dynamically allocated trampolines")
      Signed-off-by: default avatarChen Zhongjin <chenzhongjin@huawei.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20220819084334.244016-1-chenzhongjin@huawei.com
      
      
      Signed-off-by: default avatarChen Zhongjin <chenzhongjin@huawei.com>
      Reviewed-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      70b4c071
    • Zqiang's avatar
      usb: gadget: function: printer: fix use-after-free in __lock_acquire · cc6c9fa6
      Zqiang authored
      stable inclusion
      from stable-v4.19.154
      commit cedb0187b8ba929c3f76f28e6bc25804d65f8a54
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5PB1E
      
      
      CVE: CVE-2020-27784
      
      ---------------------------
      
      [ Upstream commit e8d5f92b ]
      
      Fix this by increase object reference count.
      
      BUG: KASAN: use-after-free in __lock_acquire+0x3fd4/0x4180
      kernel/locking/lockdep.c:3831
      Read of size 8 at addr ffff8880683b0018 by task syz-executor.0/3377
      
      CPU: 1 PID: 3377 Comm: syz-executor.0 Not tainted 5.6.11 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xce/0x128 lib/dump_stack.c:118
       print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374
       __kasan_report+0x131/0x1b0 mm/kasan/report.c:506
       kasan_report+0x12/0x20 mm/kasan/common.c:641
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
       __lock_acquire+0x3fd4/0x4180 kernel/locking/lockdep.c:3831
       lock_acquire+0x127/0x350 kernel/locking/lockdep.c:4488
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
       printer_ioctl+0x4a/0x110 drivers/usb/gadget/function/f_printer.c:723
       vfs_ioctl fs/ioctl.c:47 [inline]
       ksys_ioctl+0xfb/0x130 fs/ioctl.c:763
       __do_sys_ioctl fs/ioctl.c:772 [inline]
       __se_sys_ioctl fs/ioctl.c:770 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:770
       do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4531a9
      Code: ed 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48
      89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
      01 f0 ff ff 0f 83 bb 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fd14ad72c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 000000000073bfa8 RCX: 00000000004531a9
      RDX: fffffffffffffff9 RSI: 000000000000009e RDI: 0000000000000003
      RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004bbd61
      R13: 00000000004d0a98 R14: 00007fd14ad736d4 R15: 00000000ffffffff
      
      Allocated by task 2393:
       save_stack+0x21/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       __kasan_kmalloc.constprop.3+0xa7/0xd0 mm/kasan/common.c:515
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529
       kmem_cache_alloc_trace+0xfa/0x2d0 mm/slub.c:2813
       kmalloc include/linux/slab.h:555 [inline]
       kzalloc include/linux/slab.h:669 [inline]
       gprinter_alloc+0xa1/0x870 drivers/usb/gadget/function/f_printer.c:1416
       usb_get_function+0x58/0xc0 drivers/usb/gadget/functions.c:61
       config_usb_cfg_link+0x1ed/0x3e0 drivers/usb/gadget/configfs.c:444
       configfs_symlink+0x527/0x11d0 fs/configfs/symlink.c:202
       vfs_symlink+0x33d/0x5b0 fs/namei.c:4201
       do_symlinkat+0x11b/0x1d0 fs/namei.c:4228
       __do_sys_symlinkat fs/namei.c:4242 [inline]
       __se_sys_symlinkat fs/namei.c:4239 [inline]
       __x64_sys_symlinkat+0x73/0xb0 fs/namei.c:4239
       do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 3368:
       save_stack+0x21/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       kasan_set_free_info mm/kasan/common.c:337 [inline]
       __kasan_slab_free+0x135/0x190 mm/kasan/common.c:476
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:485
       slab_free_hook mm/slub.c:1444 [inline]
       slab_free_freelist_hook mm/slub.c:1477 [inline]
       slab_free mm/slub.c:3034 [inline]
       kfree+0xf7/0x410 mm/slub.c:3995
       gprinter_free+0x49/0xd0 drivers/usb/gadget/function/f_printer.c:1353
       usb_put_function+0x38/0x50 drivers/usb/gadget/functions.c:87
       config_usb_cfg_unlink+0x2db/0x3b0 drivers/usb/gadget/configfs.c:485
       configfs_unlink+0x3b9/0x7f0 fs/configfs/symlink.c:250
       vfs_unlink+0x287/0x570 fs/namei.c:4073
       do_unlinkat+0x4f9/0x620 fs/namei.c:4137
       __do_sys_unlink fs/namei.c:4184 [inline]
       __se_sys_unlink fs/namei.c:4182 [inline]
       __x64_sys_unlink+0x42/0x50 fs/namei.c:4182
       do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8880683b0000
       which belongs to the cache kmalloc-1k of size 1024
      The buggy address is located 24 bytes inside of
       1024-byte region [ffff8880683b0000, ffff8880683b0400)
      The buggy address belongs to the page:
      page:ffffea0001a0ec00 refcount:1 mapcount:0 mapping:ffff88806c00e300
      index:0xffff8880683b1800 compound_mapcount: 0
      flags: 0x100000000010200(slab|head)
      raw: 0100000000010200 0000000000000000 0000000600000001 ffff88806c00e300
      raw: ffff8880683b1800 000000008010000a 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Reported-by: default avatarKyungtae Kim <kt0755@gmail.com>
      Signed-off-by: default avatarZqiang <qiang.zhang@windriver.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarWei Li <liwei391@huawei.com>
      Reviewed-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reviewed-by: default avatarWang Weiyang <wangweiyang2@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      cc6c9fa6
  2. Sep 06, 2022
  3. Sep 05, 2022
    • Luo Meng's avatar
      dm-thin: Resume failed in FAIL mode · b3ed949d
      Luo Meng authored
      hulk inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5P05D
      
      
      CVE: NA
      
      --------------------------------
      
      When thinpool is suspended and sets fail_io, resume will report error
      as below:
      device-mapper: resume ioctl on vg-thinpool  failed: Invalid argument
      
      Thinpool also can't be removed if bio is in deferred list.
      
      This can be easily reproduced using:
      
        echo "offline" > /sys/block/sda/device/state
        dd if=/dev/zero of=/dev/mapper/thin bs=4K count=1
        dmsetup suspend /dev/mapper/pool
        mkfs.ext4 /dev/mapper/thin
        dmsetup resume /dev/mapper/pool
      
      The root cause is maybe_resize_data_dev() will check fail_io and return
      error before called dm_resume.
      
      Fix this by adding FAIL mode check at the end of  pool_preresume().
      
      Fixes: da105ed5 (dm thin metadata: introduce dm_pool_abort_metadata)
      Signed-off-by: default avatarLuo Meng <luomeng12@huawei.com>
      Reviewed-by: default avatarHou Tao <houtao1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
    • Lino Sanfilippo's avatar
      tpm: fix reference counting for struct tpm_chip · 51cd4702
      Lino Sanfilippo authored
      stable inclusion
      from stable-v4.19.237
      commit cb64bd038beacb4331fe464a36c8b5481e8f51e2
      category: bugfix
      bugzilla: 187564,https://gitee.com/src-openeuler/kernel/issues/I5NWPR
      
      
      CVE: CVE-2022-2977
      
      --------------------------------
      
      commit 7e0438f83dc769465ee663bb5dcf8cc154940712 upstream.
      
      The following sequence of operations results in a refcount warning:
      
      1. Open device /dev/tpmrm.
      2. Remove module tpm_tis_spi.
      3. Write a TPM command to the file descriptor opened at step 1.
      
      ------------[ cut here ]------------
      WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
      refcount_t: addition on 0; use-after-free.
      Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac
      sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4
      brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes
      raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm
      snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]
      CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2
      Hardware name: BCM2711
      [<c0410c3c>] (unwind_backtrace) from [<c040b580>] (show_stack+0x10/0x14)
      [<c040b580>] (show_stack) from [<c1092174>] (dump_stack+0xc4/0xd8)
      [<c1092174>] (dump_stack) from [<c0445a30>] (__warn+0x104/0x108)
      [<c0445a30>] (__warn) from [<c0445aa8>] (warn_slowpath_fmt+0x74/0xb8)
      [<c0445aa8>] (warn_slowpath_fmt) from [<c08435d0>] (kobject_get+0xa0/0xa4)
      [<c08435d0>] (kobject_get) from [<bf0a715c>] (tpm_try_get_ops+0x14/0x54 [tpm])
      [<bf0a715c>] (tpm_try_get_ops [tpm]) from [<bf0a7d6c>] (tpm_common_write+0x38/0x60 [tpm])
      [<bf0a7d6c>] (tpm_common_write [tpm]) from [<c05a7ac0>] (vfs_write+0xc4/0x3c0)
      [<c05a7ac0>] (vfs_write) from [<c05a7ee4>] (ksys_write+0x58/0xcc)
      [<c05a7ee4>] (ksys_write) from [<c04001a0>] (ret_fast_syscall+0x0/0x4c)
      Exception stack(0xc226bfa8 to 0xc226bff0)
      bfa0:                   00000000 000105b4 00000003 beafe664 00000014 00000000
      bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684
      bfe0: 0000006c beafe648 0001056c b6eb6944
      ---[ end trace d4b8409def9b8b1f ]---
      
      The reason for this warning is the attempt to get the chip->dev reference
      in tpm_common_write() although the reference counter is already zero.
      
      Since commit 8979b02a ("tpm: Fix reference count to main device") the
      extra reference used to prevent a premature zero counter is never taken,
      because the required TPM_CHIP_FLAG_TPM2 flag is never set.
      
      Fix this by moving the TPM 2 character device handling from
      tpm_chip_alloc() to tpm_add_char_device() which is called at a later point
      in time when the flag has been set in case of TPM2.
      
      Commit fdc915f7 ("tpm: expose spaces via a device link /dev/tpmrm<n>")
      already introduced function tpm_devs_release() to release the extra
      reference but did not implement the required put on chip->devs that results
      in the call of this function.
      
      Fix this by putting chip->devs in tpm_chip_unregister().
      
      Finally move the new implementation for the TPM 2 handling into a new
      function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the
      good case and error cases.
      
      Cc: stable@vger.kernel.org
      Fixes: fdc915f7 ("tpm: expose spaces via a device link /dev/tpmrm<n>")
      Fixes: 8979b02a ("tpm: Fix reference count to main device")
      Co-developed-by: default avatarJason Gunthorpe <jgg@ziepe.ca>
      Signed-off-by: default avatarJason Gunthorpe <jgg@ziepe.ca>
      Signed-off-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
      Tested-by: default avatarStefan Berger <stefanb@linux.ibm.com>
      Reviewed-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarHui Tang <tanghui20@huawei.com>
      Reviewed-by: default avatarZhang Qiao <zhangqiao22@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      51cd4702
    • Herbert Xu's avatar
      af_key: Do not call xfrm_probe_algs in parallel · b4649d7c
      Herbert Xu authored
      mainline inclusion
      from mainline-v6.0-rc3
      commit ba953a9d89a00c078b85f4b190bc1dde66fe16b5
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5OPA4
      
      
      CVE: CVE-2022-3028
      
      --------------------------------
      
      When namespace support was added to xfrm/afkey, it caused the
      previously single-threaded call to xfrm_probe_algs to become
      multi-threaded.  This is buggy and needs to be fixed with a mutex.
      
      Reported-by: default avatarAbhishek Shah <abhishek.shah@columbia.edu>
      Fixes: 283bc9f3 ("xfrm: Namespacify xfrm state/policy locks")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarXu Jia <xujia39@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarWang Weiyang <wangweiyang2@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      b4649d7c
  4. Sep 01, 2022
    • Jose Alonso's avatar
      net: usb: ax88179_178a: Fix packet receiving · 24d2149f
      Jose Alonso authored
      stable inclusion
      from stable-v4.19.251
      commit 5fabd32fd5492675e33a7ca972ac158e7b7361ee
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5NYS6
      
      
      CVE: CVE-2022-2964
      
      ---------------------------
      
      commit f8ebb3ac881b17712e1d5967c97ab1806b16d3d6 upstream.
      
      This patch corrects packet receiving in ax88179_rx_fixup.
      
      - problem observed:
        ifconfig shows allways a lot of 'RX Errors' while packets
        are received normally.
      
        This occurs because ax88179_rx_fixup does not recognise properly
        the usb urb received.
        The packets are normally processed and at the end, the code exits
        with 'return 0', generating RX Errors.
        (pkt_cnt==-2 and ptk_hdr over field rx_hdr trying to identify
         another packet there)
      
        This is a usb urb received by "tcpdump -i usbmon2 -X" on a
        little-endian CPU:
        0x0000:  eeee f8e3 3b19 87a0 94de 80e3 daac 0800
                 ^         packet 1 start (pkt_len = 0x05ec)
                 ^^^^      IP alignment pseudo header
                      ^    ethernet packet start
                 last byte ethernet packet   v
                 padding (8-bytes aligned)     vvvv vvvv
        0x05e0:  c92d d444 1420 8a69 83dd 272f e82b 9811
        0x05f0:  eeee f8e3 3b19 87a0 94de 80e3 daac 0800
        ...      ^ packet 2
        0x0be0:  eeee f8e3 3b19 87a0 94de 80e3 daac 0800
        ...
        0x1130:  9d41 9171 8a38 0ec5 eeee f8e3 3b19 87a0
        ...
        0x1720:  8cfc 15ff 5e4c e85c eeee f8e3 3b19 87a0
        ...
        0x1d10:  ecfa 2a3a 19ab c78c eeee f8e3 3b19 87a0
        ...
        0x2070:  eeee f8e3 3b19 87a0 94de 80e3 daac 0800
        ...      ^ packet 7
        0x2120:  7c88 4ca5 5c57 7dcc 0d34 7577 f778 7e0a
        0x2130:  f032 e093 7489 0740 3008 ec05 0000 0080
                                     ====1==== ====2====
                 hdr_off             ^
                 pkt_len = 0x05ec         ^^^^
                 AX_RXHDR_*=0x00830  ^^^^   ^
                 pkt_len = 0                        ^^^^
                 AX_RXHDR_DROP_ERR=0x80000000  ^^^^   ^
        0x2140:  3008 ec05 0000 0080 3008 5805 0000 0080
        0x2150:  3008 ec05 0000 0080 3008 ec05 0000 0080
        0x2160:  3008 5803 0000 0080 3008 c800 0000 0080
                 ===11==== ===12==== ===13==== ===14====
        0x2170:  0000 0000 0e00 3821
                           ^^^^ ^^^^ rx_hdr
                           ^^^^      pkt_cnt=14
                                ^^^^ hdr_off=0x2138
                 ^^^^ ^^^^           padding
      
        The dump shows that pkt_cnt is the number of entrys in the
        per-packet metadata. It is "2 * packet count".
        Each packet have two entrys. The first have a valid
        value (pkt_len and AX_RXHDR_*) and the second have a
        dummy-header 0x80000000 (pkt_len=0 with AX_RXHDR_DROP_ERR).
        Why exists dummy-header for each packet?!?
        My guess is that this was done probably to align the
        entry for each packet to 64-bits and maintain compatibility
        with old firmware.
        There is also a padding (0x00000000) before the rx_hdr to
        align the end of rx_hdr to 64-bit.
        Note that packets have a alignment of 64-bits (8-bytes).
      
        This patch assumes that the dummy-header and the last
        padding are optional. So it preserves semantics and
        recognises the same valid packets as the current code.
      
        This patch was made using only the dumpfile information and
        tested with only one device:
        0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
      
      Fixes: 57bc3d3ae8c1 ("net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup")
      Fixes: e2ca90c2 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
      Signed-off-by: default avatarJose Alonso <joalonsof@gmail.com>
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Link: https://lore.kernel.org/r/d6970bb04bf67598af4d316eaeb1792040b18cfd.camel@gmail.com
      
      
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      (cherry picked from commit 5fabd32fd5492675e33a7ca972ac158e7b7361ee)
      Signed-off-by: default avatarLiu Jian <liujian56@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      24d2149f
    • Jann Horn's avatar
      net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup · b6ca9563
      Jann Horn authored
      stable inclusion
      from stable-v4.19.231
      commit 1668781ed24da43498799aa4f65714a7de201930
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5NYS6
      
      
      CVE: CVE-2022-2964
      
      ---------------------------
      
      commit 57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581 upstream.
      
      ax88179_rx_fixup() contains several out-of-bounds accesses that can be
      triggered by a malicious (or defective) USB device, in particular:
      
       - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds,
         causing OOB reads and (on big-endian systems) OOB endianness flips.
       - A packet can overlap the metadata array, causing a later OOB
         endianness flip to corrupt data used by a cloned SKB that has already
         been handed off into the network stack.
       - A packet SKB can be constructed whose tail is far beyond its end,
         causing out-of-bounds heap data to be considered part of the SKB's
         data.
      
      I have tested that this can be used by a malicious USB device to send a
      bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response
      that contains random kernel heap data.
      It's probably also possible to get OOB writes from this on a
      little-endian system somehow - maybe by triggering skb_cow() via IP
      options processing -, but I haven't tested that.
      
      Fixes: e2ca90c2 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
      Cc: stable@kernel.org
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      (cherry picked from commit 1668781ed24da43498799aa4f65714a7de201930)
      Signed-off-by: default avatarLiu Jian <liujian56@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      b6ca9563
    • Jeremy Kerr's avatar
      net: usb: ax88179_178a: fix packet alignment padding · e17f1289
      Jeremy Kerr authored
      stable inclusion
      from stable-v4.19.131
      commit c191f7cf369c0090fdbeff0b6782d5eaa3a179d2
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5NYS6
      
      
      CVE: CVE-2022-2964
      
      ---------------------------
      
      [ Upstream commit e869e7a1 ]
      
      Using a AX88179 device (0b95:1790), I see two bytes of appended data on
      every RX packet. For example, this 48-byte ping, using 0xff as a
      payload byte:
      
        04:20:22.528472 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 2447, seq 1, length 64
      	0x0000:  000a cd35 ea50 000a cd35 ea4f 0800 4500
      	0x0010:  0054 c116 4000 4001 f63e c0a8 0101 c0a8
      	0x0020:  0102 0800 b633 098f 0001 87ea cd5e 0000
      	0x0030:  0000 dcf2 0600 0000 0000 ffff ffff ffff
      	0x0040:  ffff ffff ffff ffff ffff ffff ffff ffff
      	0x0050:  ffff ffff ffff ffff ffff ffff ffff ffff
      	0x0060:  ffff 961f
      
      Those last two bytes - 96 1f - aren't part of the original packet.
      
      In the ax88179 RX path, the usbnet rx_fixup function trims a 2-byte
      'alignment pseudo header' from the start of the packet, and sets the
      length from a per-packet field populated by hardware. It looks like that
      length field *includes* the 2-byte header; the current driver assumes
      that it's excluded.
      
      This change trims the 2-byte alignment header after we've set the packet
      length, so the resulting packet length is correct. While we're moving
      the comment around, this also fixes the spelling of 'pseudo'.
      
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      (cherry picked from commit c191f7cf369c0090fdbeff0b6782d5eaa3a179d2)
      Signed-off-by: default avatarLiu Jian <liujian56@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      e17f1289
  5. Aug 29, 2022
  6. Aug 27, 2022
  7. Aug 26, 2022
  8. Aug 25, 2022
  9. Aug 23, 2022
  10. Aug 19, 2022
    • Pawan Gupta's avatar
      x86/speculation: Add LFENCE to RSB fill sequence · 6586edc6
      Pawan Gupta authored
      stable inclusion
      from stable-v4.19.255
      commit b1c9f470fb724d3cfd6cf8fe4a70c2ec4de2e9f4
      category: bugfix
      bugzilla: 187492, https://gitee.com/src-openeuler/kernel/issues/I5N1SO
      
      
      CVE: CVE-2022-26373
      
      --------------------------------
      
      commit ba6e31af2be96c4d0536f2152ed6f7b6c11bca47 upstream.
      
      RSB fill sequence does not have any protection for miss-prediction of
      conditional branch at the end of the sequence. CPU can speculatively
      execute code immediately after the sequence, while RSB filling hasn't
      completed yet.
      
        #define __FILL_RETURN_BUFFER(reg, nr, sp)	\
        	mov	$(nr/2), reg;			\
        771:						\
        	call	772f;				\
        773:	/* speculation trap */			\
        	pause;					\
        	lfence;					\
        	jmp	773b;				\
        772:						\
        	call	774f;				\
        775:	/* speculation trap */			\
        	pause;					\
        	lfence;					\
        	jmp	775b;				\
        774:						\
        	dec	reg;				\
        	jnz	771b;  <----- CPU can miss-predict here.				\
        	add	$(BITS_PER_LONG/8) * nr, sp;
      
      Before RSB is filled, RETs that come in program order after this macro
      can be executed speculatively, making them vulnerable to RSB-based
      attacks.
      
      Mitigate it by adding an LFENCE after the conditional branch to prevent
      speculation while RSB is being filled.
      
      Suggested-by: default avatarAndrew Cooper <andrew.cooper3@citrix.com>
      Signed-off-by: default avatarPawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarChen Jiahao <chenjiahao16@huawei.com>
      Reviewed-by: default avatarZhang Jianhua <chris.zjh@huawei.com>
      Reviewed-by: default avatarLiao Chang <liaochang1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
    • Daniel Sneddon's avatar
      x86/speculation: Add RSB VM Exit protections · 42268ea1
      Daniel Sneddon authored
      stable inclusion
      from stable-v4.19.255
      commit b6c5011934a15762cd694e36fe74f2f2f93eac9b
      category: bugfix
      bugzilla: 187492, https://gitee.com/src-openeuler/kernel/issues/I5N1SO
      
      
      CVE: CVE-2022-26373
      
      --------------------------------
      
      commit 2b1299322016731d56807aa49254a5ea3080b6b3 upstream.
      
      tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as
      documented for RET instructions after VM exits. Mitigate it with a new
      one-entry RSB stuffing mechanism and a new LFENCE.
      
      == Background ==
      
      Indirect Branch Restricted Speculation (IBRS) was designed to help
      mitigate Branch Target Injection and Speculative Store Bypass, i.e.
      Spectre, attacks. IBRS prevents software run in less privileged modes
      from affecting branch prediction in more privileged modes. IBRS requires
      the MSR to be written on every privilege level change.
      
      To overcome some of the performance issues of IBRS, Enhanced IBRS was
      introduced.  eIBRS is an "always on" IBRS, in other words, just turn
      it on once instead of writing the MSR on every privilege level change.
      When eIBRS is enabled, more privileged modes should be protected from
      less privileged modes, including protecting VMMs from guests.
      
      == Problem ==
      
      Here's a simplification of how guests are run on Linux' KVM:
      
      void run_kvm_guest(void)
      {
      	// Prepare to run guest
      	VMRESUME();
      	// Clean up after guest runs
      }
      
      The execution flow for that would look something like this to the
      processor:
      
      1. Host-side: call run_kvm_guest()
      2. Host-side: VMRESUME
      3. Guest runs, does "CALL guest_function"
      4. VM exit, host runs again
      5. Host might make some "cleanup" function calls
      6. Host-side: RET from run_kvm_guest()
      
      Now, when back on the host, there are a couple of possible scenarios of
      post-guest activity the host needs to do before executing host code:
      
      * on pre-eIBRS hardware (legacy IBRS, or nothing at all), the RSB is not
      touched and Linux has to do a 32-entry stuffing.
      
      * on eIBRS hardware, VM exit with IBRS enabled, or restoring the host
      IBRS=1 shortly after VM exit, has a documented side effect of flushing
      the RSB except in this PBRSB situation where the software needs to stuff
      the last RSB entry "by hand".
      
      IOW, with eIBRS supported, host RET instructions should no longer be
      influenced by guest behavior after the host retires a single CALL
      instruction.
      
      However, if the RET instructions are "unbalanced" with CALLs after a VM
      exit as is the RET in #6, it might speculatively use the address for the
      instruction after the CALL in #3 as an RSB prediction. This is a problem
      since the (untrusted) guest controls this address.
      
      Balanced CALL/RET instruction pairs such as in step #5 are not affected.
      
      == Solution ==
      
      The PBRSB issue affects a wide variety of Intel processors which
      support eIBRS. But not all of them need mitigation. Today,
      X86_FEATURE_RETPOLINE triggers an RSB filling sequence that mitigates
      PBRSB. Systems setting RETPOLINE need no further mitigation - i.e.,
      eIBRS systems which enable retpoline explicitly.
      
      However, such systems (X86_FEATURE_IBRS_ENHANCED) do not set RETPOLINE
      and most of them need a new mitigation.
      
      Therefore, introduce a new feature flag X86_FEATURE_RSB_VMEXIT_LITE
      which triggers a lighter-weight PBRSB mitigation versus RSB Filling at
      vmexit.
      
      The lighter-weight mitigation performs a CALL instruction which is
      immediately followed by a speculative execution barrier (INT3). This
      steers speculative execution to the barrier -- just like a retpoline
      -- which ensures that speculation can never reach an unbalanced RET.
      Then, ensure this CALL is retired before continuing execution with an
      LFENCE.
      
      In other words, the window of exposure is opened at VM exit where RET
      behavior is troublesome. While the window is open, force RSB predictions
      sampling for RET targets to a dead end at the INT3. Close the window
      with the LFENCE.
      
      There is a subset of eIBRS systems which are not vulnerable to PBRSB.
      Add these systems to the cpu_vuln_whitelist[] as NO_EIBRS_PBRSB.
      Future systems that aren't vulnerable will set ARCH_CAP_PBRSB_NO.
      
        [ bp: Massage, incorporate review comments from Andy Cooper. ]
        [ Pawan: Update commit message to replace RSB_VMEXIT with RETPOLINE ]
      
      Signed-off-by: default avatarDaniel Sneddon <daniel.sneddon@linux.intel.com>
      Co-developed-by: default avatarPawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Signed-off-by: default avatarPawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      conflict:
          arch/x86/include/asm/cpufeatures.h
          arch/x86/kernel/cpu/common.c
      
      Signed-off-by: default avatarChen Jiahao <chenjiahao16@huawei.com>
      Reviewed-by: default avatarZhang Jianhua <chris.zjh@huawei.com>
      Reviewed-by: default avatarLiao Chang <liaochang1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      42268ea1