CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48728 – IB/hfi1: Fix AIP early init panic
https://notcve.org/view.php?id=CVE-2022-48728
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix AIP early init panic An early failure in hfi1_ipoib_setup_rn() can lead to the following panic: BUG: unable to handle kernel NULL pointer dereference at 00000000000001b0 PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI Workqueue: events work_for_cpu_fn RIP: 0010:try_to_grab_pending+0x2b/0x140 Code: 1f 44 00 00 41 55 41 54 55 48 89 d5 53 48 89 fb 9c 58 0f 1f 44 00 00 48 89 c2 fa 66 0f 1f 44 00 00 48 89 55 00 40 84 f6 75 77 <f0> 48 0f ba 2b 00 72 09 31 c0 5b 5d 41 5c 41 5d c3 48 89 df e8 6c RSP: 0018:ffffb6b3cf7cfa48 EFLAGS: 00010046 RAX: 0000000000000246 RBX: 00000000000001b0 RCX: 0000000000000000 RDX: 0000000000000246 RSI: 0000000000000000 RDI: 00000000000001b0 RBP: ffffb6b3cf7cfa70 R08: 0000000000000f09 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: ffffb6b3cf7cfa90 R14: ffffffff9b2fbfc0 R15: ffff8a4fdf244690 FS: 0000000000000000(0000) GS:ffff8a527f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000001b0 CR3: 00000017e2410003 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __cancel_work_timer+0x42/0x190 ? dev_printk_emit+0x4e/0x70 iowait_cancel_work+0x15/0x30 [hfi1] hfi1_ipoib_txreq_deinit+0x5a/0x220 [hfi1] ? dev_err+0x6c/0x90 hfi1_ipoib_netdev_dtor+0x15/0x30 [hfi1] hfi1_ipoib_setup_rn+0x10e/0x150 [hfi1] rdma_init_netdev+0x5a/0x80 [ib_core] ? hfi1_ipoib_free_rdma_netdev+0x20/0x20 [hfi1] ipoib_intf_init+0x6c/0x350 [ib_ipoib] ipoib_intf_alloc+0x5c/0xc0 [ib_ipoib] ipoib_add_one+0xbe/0x300 [ib_ipoib] add_client_context+0x12c/0x1a0 [ib_core] enable_device_and_get+0xdc/0x1d0 [ib_core] ib_register_device+0x572/0x6b0 [ib_core] rvt_register_device+0x11b/0x220 [rdmavt] hfi1_register_ib_device+0x6b4/0x770 [hfi1] do_init_one.isra.20+0x3e3/0x680 [hfi1] local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x1cf/0x390 ? • https://git.kernel.org/stable/c/d99dc602e2a55a99940ba9506a7126dfa54d54ea https://git.kernel.org/stable/c/4a9bd1e6780fc59f81466ec3489d5ad535a37190 https://git.kernel.org/stable/c/a3dd4d2682f2a796121609e5f3bbeb1243198c53 https://git.kernel.org/stable/c/1899c3cad265c4583658aed5293d02e8af84276b https://git.kernel.org/stable/c/5f8f55b92edd621f056bdf09e572092849fabd83 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48727 – KVM: arm64: Avoid consuming a stale esr value when SError occur
https://notcve.org/view.php?id=CVE-2022-48727
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Avoid consuming a stale esr value when SError occur When any exception other than an IRQ occurs, the CPU updates the ESR_EL2 register with the exception syndrome. An SError may also become pending, and will be synchronised by KVM. KVM notes the exception type, and whether an SError was synchronised in exit_code. When an exception other than an IRQ occurs, fixup_guest_exit() updates vcpu->arch.fault.esr_el2 from the hardware register. When an SError was synchronised, the vcpu esr value is used to determine if the exception was due to an HVC. If so, ELR_EL2 is moved back one instruction. • https://git.kernel.org/stable/c/defe21f49bc98b095300752aa1e19bb608f3e97d https://git.kernel.org/stable/c/e1e852746997500f1873f60b954da5f02cc2dba3 https://git.kernel.org/stable/c/57e2986c3b25092691a6e3d6ee9168caf8978932 https://git.kernel.org/stable/c/1c71dbc8a179d99dd9bb7e7fc1888db613cf85de •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48726 – RDMA/ucma: Protect mc during concurrent multicast leaves
https://notcve.org/view.php?id=CVE-2022-48726
In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Protect mc during concurrent multicast leaves Partially revert the commit mentioned in the Fixes line to make sure that allocation and erasing multicast struct are locked. BUG: KASAN: use-after-free in ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline] BUG: KASAN: use-after-free in ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579 Read of size 8 at addr ffff88801bb74b00 by task syz-executor.1/25529 CPU: 0 PID: 25529 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline] ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579 ucma_destroy_id+0x1e6/0x280 drivers/infiniband/core/ucma.c:614 ucma_write+0x25c/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xae0 fs/read_write.c:588 ksys_write+0x1ee/0x250 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Currently the xarray search can touch a concurrently freeing mc as the xa_for_each() is not surrounded by any lock. Rather than hold the lock for a full scan hold it only for the effected items, which is usually an empty list. • https://git.kernel.org/stable/c/95fe51096b7adf1d1e7315c49c75e2f75f162584 https://git.kernel.org/stable/c/75c610212b9f1756b9384911d3a2c347eee8031c https://git.kernel.org/stable/c/2923948ffe0835f7114e948b35bcc42bc9b3baa1 https://git.kernel.org/stable/c/ee2477e8ccd3d978eeac0dc5a981b286d9bb7b0a https://git.kernel.org/stable/c/36e8169ec973359f671f9ec7213547059cae972e •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48725 – RDMA/siw: Fix refcounting leak in siw_create_qp()
https://notcve.org/view.php?id=CVE-2022-48725
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix refcounting leak in siw_create_qp() The atomic_inc() needs to be paired with an atomic_dec() on the error path. • https://git.kernel.org/stable/c/514aee660df493cd673154a6ba6bab745ec47b8c https://git.kernel.org/stable/c/2989ba9532babac66e79997ccff73c015b69700c https://git.kernel.org/stable/c/fa3b844a50845c817660146c27c0fc29b08d3116 https://git.kernel.org/stable/c/a75badebfdc0b3823054bedf112edb54d6357c75 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48724 – iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping()
https://notcve.org/view.php?id=CVE-2022-48724
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping() After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated"). For tear down scenario, fn is only freed after fail to allocate ir_domain, though it also should be freed in case dmar_enable_qi returns error. Besides free fn, irq_domain and ir_msi_domain need to be removed as well if intel_setup_irq_remapping fails to enable queued invalidation. Improve the rewinding path by add out_free_ir_domain and out_free_fwnode lables per Baolu's suggestion. • https://git.kernel.org/stable/c/03992c88d71ba79d956f2ed54e370e630b8750f4 https://git.kernel.org/stable/c/c0c489e5430530a7021f4c889cd5931597e4b200 https://git.kernel.org/stable/c/36f7355545725c5e9400520ae33e6ee16cf78c0e https://git.kernel.org/stable/c/e3beca48a45b5e0e6e6a4e0124276b8248dcc9bb https://git.kernel.org/stable/c/b4198ecddb87cd955aa9e024dd656af5ceaf6196 https://git.kernel.org/stable/c/a0c685ba99961b1dd894b2e470e692a539770f6d https://git.kernel.org/stable/c/a31cb1f0fb6caf46ffe88c41252b6b7a4ee062d9 https://git.kernel.org/stable/c/5c43d46daa0d2928234dd2792ebebc35d •