CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48796 – iommu: Fix potential use-after-free during probe
https://notcve.org/view.php?id=CVE-2022-48796
In the Linux kernel, the following vulnerability has been resolved: iommu: Fix potential use-after-free during probe Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free. BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153 Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x33c show_stack+0x18/0x24 dump_stack_lvl+0x16c/0x1e0 print_address_description+0x84/0x39c __kasan_report+0x184/0x308 kasan_report+0x50/0x78 __asan_load8+0xc0/0xc4 of_iommu_configure+0xb4/0x4a4 of_dma_configure_id+0x2fc/0x4d4 platform_dma_configure+0x40/0x5c really_probe+0x1b4/0xb74 driver_probe_device+0x11c/0x228 __device_attach_driver+0x14c/0x304 bus_for_each_drv+0x124/0x1b0 __device_attach+0x25c/0x334 device_initial_probe+0x24/0x34 bus_probe_device+0x78/0x134 deferred_probe_work_func+0x130/0x1a8 process_one_work+0x4c8/0x970 worker_thread+0x5c8/0xaec kthread+0x1f8/0x220 ret_from_fork+0x10/0x18 Allocated by task 1: ____kasan_kmalloc+0xd4/0x114 __kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0xe4/0x3d4 __iommu_probe_device+0x90/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Freed by task 1: kasan_set_track+0x4c/0x84 kasan_set_free_info+0x28/0x4c ____kasan_slab_free+0x120/0x15c __kasan_slab_free+0x18/0x28 slab_free_freelist_hook+0x204/0x2fc kfree+0xfc/0x3a4 __iommu_probe_device+0x284/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Fix this by setting dev->iommu to NULL first and then freeing dev_iommu structure in dev_iommu_free function. • https://git.kernel.org/stable/c/cb86e511e78e796de6947b8f3acca1b7c76fb2ff https://git.kernel.org/stable/c/65ab30f6a6952fa9ee13009862736cf8d110e6e5 https://git.kernel.org/stable/c/f74fc4b5bd533ea3d30ce47cccb8ef8d21fda85a https://git.kernel.org/stable/c/b54240ad494300ff0994c4539a531727874381f4 https://access.redhat.com/security/cve/CVE-2022-48796 https://bugzilla.redhat.com/show_bug.cgi?id=2298132 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48795 – parisc: Fix data TLB miss in sba_unmap_sg
https://notcve.org/view.php?id=CVE-2022-48795
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix data TLB miss in sba_unmap_sg Rolf Eike Beer reported the following bug: [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000 [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001 [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001 [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0 [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007 [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001 [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0 [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118 [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800 [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [1274934.746891] [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018 [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff [1274934.746891] ORIG_R28: 0000000040acdd58 [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118 [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118 [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118 [1274934.746891] Backtrace: [1274934.746891] [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70 [1274934.746891] [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60 [1274934.746891] [<00000000407a3488>] mptscsih_io_done+0x150/0xd70 [1274934.746891] [<0000000040798600>] mpt_interrupt+0x168/0xa68 [1274934.746891] [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278 [1274934.746891] [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8 [1274934.746891] [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0 [1274934.746891] [<00000000402548e0>] generic_handle_irq+0x50/0x70 [1274934.746891] [<000000004019a254>] call_on_stack+0x18/0x24 [1274934.746891] [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?) The bug is caused by overrunning the sglist and incorrectly testing sg_dma_len(sglist) before nents. Normally this doesn't cause a crash, but in this case sglist crossed a page boundary. This occurs in the following code: while (sg_dma_len(sglist) && nents--) { The fix is simply to test nents first and move the decrement of nents into the loop. • https://git.kernel.org/stable/c/f23f0444ead4d941165aa82ce2fcbb997dc00e97 https://git.kernel.org/stable/c/de75676ee99bf9f25b1124ff301b3f7b8ba597d4 https://git.kernel.org/stable/c/867e50231c7605547d9334904d70a181f39f2d9e https://git.kernel.org/stable/c/efccc9b0c7e28d0eb7918a236e59f60dc23db4c3 https://git.kernel.org/stable/c/f8f519d7df66c334b5e08f896ac70ee3b53add3b https://git.kernel.org/stable/c/8c8e949ae81e7f5ab58f9f9f8e9b573b93173dd2 https://git.kernel.org/stable/c/e40ae3133ed87d6d526f3c8fc6a5f9a2d72dcdbf https://git.kernel.org/stable/c/b7d6f44a0fa716a82969725516dc0b16b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48794 – net: ieee802154: at86rf230: Stop leaking skb's
https://notcve.org/view.php?id=CVE-2022-48794
In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: at86rf230: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. In the Tx case we then leak the skb structure. Free the skb structure upon error before returning when appropriate. As the 'is_tx = 0' cannot be moved in the complete handler because of a possible race between the delay in switching to STATE_RX_AACK_ON and a new interrupt, we introduce an intermediate 'was_tx' boolean just for this purpose. There is no Fixes tag applying here, many changes have been made on this area and the issue kind of always existed. • https://git.kernel.org/stable/c/d2a1eaf51b7d4412319adb6acef114ba472d1692 https://git.kernel.org/stable/c/af649e5c95f56df64363bc46f6746b87819f9c0d https://git.kernel.org/stable/c/6312f6a53fd3ea38125dcaca5e3c9aa7d8a60cf7 https://git.kernel.org/stable/c/455ef08d6e5473526fa6763f75a93f7198206966 https://git.kernel.org/stable/c/0fd484644c68897c490a3307bfcc8bf767df5a43 https://git.kernel.org/stable/c/23b2a25382400168427ea278f3d8bf4ecfd333bf https://git.kernel.org/stable/c/1c72f04d52b7200bb83426a9bed378668271ea4a https://git.kernel.org/stable/c/e5ce576d45bf72fd0e3dc37eff897bfcc •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48793 – KVM: x86: nSVM: fix potential NULL derefernce on nested migration
https://notcve.org/view.php?id=CVE-2022-48793
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: nSVM: fix potential NULL derefernce on nested migration Turns out that due to review feedback and/or rebases I accidentally moved the call to nested_svm_load_cr3 to be too early, before the NPT is enabled, which is very wrong to do. KVM can't even access guest memory at that point as nested NPT is needed for that, and of course it won't initialize the walk_mmu, which is main issue the patch was addressing. Fix this for real. A vulnerability was found in the nested.c file in the Linux kernel's KVM driver, where a potential NULL dereference can occur. This happens when the call to load the nested state is executed before Nested Page Tables (NPT) are enabled, preventing access to guest memory, lead to system instability and a denial of service during nested migration processes. • https://git.kernel.org/stable/c/232f75d3b4b5456de6f0b671aa86345d62de1473 https://git.kernel.org/stable/c/74b426bea4f7e3b081add2b88d4fba16d3af7ab6 https://git.kernel.org/stable/c/352193edda48e08e8824a7ece09aec830a603cfe https://git.kernel.org/stable/c/e1779c2714c3023e4629825762bcbc43a3b943df https://access.redhat.com/security/cve/CVE-2022-48793 https://bugzilla.redhat.com/show_bug.cgi?id=2298129 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48792 – scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task
https://notcve.org/view.php?id=CVE-2022-48792
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task Currently a use-after-free may occur if a sas_task is aborted by the upper layer before we handle the I/O completion in mpi_ssp_completion() or mpi_sata_completion(). In this case, the following are the two steps in handling those I/O completions: - Call complete() to inform the upper layer handler of completion of the I/O. - Release driver resources associated with the sas_task in pm8001_ccb_task_free() call. When complete() is called, the upper layer may free the sas_task. As such, we should not touch the associated sas_task afterwards, but we do so in the pm8001_ccb_task_free() call. Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering. • https://git.kernel.org/stable/c/fe9ac3eaa2e387a5742b380b73a5a6bc237bf184 https://git.kernel.org/stable/c/d9d93f32534a0a80a1c26bdb0746d90a7b19c2c2 https://git.kernel.org/stable/c/f61f9fccb2cb4bb275674a79d638704db6bc2171 https://git.kernel.org/stable/c/df7abcaa1246e2537ab4016077b5443bb3c09378 •