CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48804 – vt_ioctl: fix array_index_nospec in vt_setactivate
https://notcve.org/view.php?id=CVE-2022-48804
In the Linux kernel, the following vulnerability has been resolved: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. • https://git.kernel.org/stable/c/830c5aa302ec16b4ee641aec769462c37f802c90 https://git.kernel.org/stable/c/2a45a6bd1e6d651770aafff57ab3e1d3bb0b42e0 https://git.kernel.org/stable/c/170325aba4608bde3e7d21c9c19b7bc266ac0885 https://git.kernel.org/stable/c/ae3d57411562260ee3f4fd5e875f410002341104 https://git.kernel.org/stable/c/778302ca09498b448620edd372dc908bebf80bdf https://git.kernel.org/stable/c/ffe54289b02e9c732d6f04c8ebbe3b2d90d32118 https://git.kernel.org/stable/c/6550bdf52846f85a2a3726a5aa0c7c4399f2fc02 https://git.kernel.org/stable/c/61cc70d9e8ef5b042d4ed87994d20100e •
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: -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 •