Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: CPPC: Avoid out of bounds access when parsing _CPC data<br /> <br /> If the NumEntries field in the _CPC return package is less than 2, do<br /> not attempt to access the "Revision" element of that package, because<br /> it may not be present then.<br /> <br /> BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio: use virtio_device_ready() in virtio_device_restore()<br /> <br /> After waking up a suspended VM, the kernel prints the following trace<br /> for virtio drivers which do not directly call virtio_device_ready() in<br /> the .restore:<br /> <br /> PM: suspend exit<br /> irq 22: nobody cared (try booting with the "irqpoll" option)<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x38/0x49<br /> dump_stack+0x10/0x12<br /> __report_bad_irq+0x3a/0xaf<br /> note_interrupt.cold+0xb/0x60<br /> handle_irq_event+0x71/0x80<br /> handle_fasteoi_irq+0x95/0x1e0<br /> __common_interrupt+0x6b/0x110<br /> common_interrupt+0x63/0xe0<br /> asm_common_interrupt+0x1e/0x40<br /> ? __do_softirq+0x75/0x2f3<br /> irq_exit_rcu+0x93/0xe0<br /> sysvec_apic_timer_interrupt+0xac/0xd0<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> arch_cpu_idle+0x12/0x20<br /> default_idle_call+0x39/0xf0<br /> do_idle+0x1b5/0x210<br /> cpu_startup_entry+0x20/0x30<br /> start_secondary+0xf3/0x100<br /> secondary_startup_64_no_verify+0xc3/0xcb<br /> <br /> handlers:<br /> [] vp_interrupt<br /> [] vp_interrupt<br /> Disabling IRQ #22<br /> <br /> This happens because we don&amp;#39;t invoke .enable_cbs callback in<br /> virtio_device_restore(). That callback is used by some transports<br /> (e.g. virtio-pci) to enable interrupts.<br /> <br /> Let&amp;#39;s fix it, by calling virtio_device_ready() as we do in<br /> virtio_dev_probe(). This function calls .enable_cts callback and sets<br /> DRIVER_OK status bit.<br /> <br /> This fix also avoids setting DRIVER_OK twice for those drivers that<br /> call virtio_device_ready() in the .restore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Fix the maximum minor value is blk_alloc_ext_minor()<br /> <br /> ida_alloc_range(..., min, max, ...) returns values from min to max,<br /> inclusive.<br /> <br /> So, NR_EXT_DEVT is a valid idx returned by blk_alloc_ext_minor().<br /> <br /> This is an issue because in device_add_disk(), this value is used in:<br /> ddev-&gt;devt = MKDEV(disk-&gt;major, disk-&gt;first_minor);<br /> and NR_EXT_DEVT is &amp;#39;(1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watch_queue: Free the page array when watch_queue is dismantled<br /> <br /> Commit 7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the<br /> watch_queue is torn down") took care of the bitmap, but not the page<br /> array.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810d9bc140 (size 32):<br /> comm "syz-executor335", pid 3603, jiffies 4294946994 (age 12.840s)<br /> hex dump (first 32 bytes):<br /> 40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@.............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> kmalloc_array include/linux/slab.h:621 [inline]<br /> kcalloc include/linux/slab.h:652 [inline]<br /> watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251<br /> pipe_ioctl+0x82/0x140 fs/pipe.c:632<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ref_tracker: implement use-after-free detection<br /> <br /> Whenever ref_tracker_dir_init() is called, mark the struct ref_tracker_dir<br /> as dead.<br /> <br /> Test the dead status from ref_tracker_alloc() and ref_tracker_free()<br /> <br /> This should detect buggy dev_put()/dev_hold() happening too late<br /> in netdevice dismantle process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: Add missing pm_runtime_put_sync<br /> <br /> pm_runtime_get_sync() will increase the rumtime PM counter<br /> even when it returns an error. Thus a pairing decrement is needed<br /> to prevent refcount leak. Fix this by replacing this API with<br /> pm_runtime_resume_and_get(), which will not change the runtime<br /> PM counter on error. Besides, a matching decrement is needed<br /> on the error handling path to keep the counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921: fix crash when startup fails.<br /> <br /> If the nic fails to start, it is possible that the<br /> reset_work has already been scheduled. Ensure the<br /> work item is canceled so we do not have use-after-free<br /> crash in case cleanup is called before the work item<br /> is executed.<br /> <br /> This fixes crash on my x86_64 apu2 when mt7921k radio<br /> fails to work. Radio still fails, but OS does not<br /> crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: mhi: use mhi_sync_power_up()<br /> <br /> If amss.bin was missing ath11k would crash during &amp;#39;rmmod ath11k_pci&amp;#39;. The<br /> reason for that was that we were using mhi_async_power_up() which does not<br /> check any errors. But mhi_sync_power_up() on the other hand does check for<br /> errors so let&amp;#39;s use that to fix the crash.<br /> <br /> I was not able to find a reason why an async version was used.<br /> ath11k_mhi_start() (which enables state ATH11K_MHI_POWER_ON) is called from<br /> ath11k_hif_power_up(), which can sleep. So sync version should be safe to use<br /> here.<br /> <br /> [ 145.569731] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI<br /> [ 145.569789] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> [ 145.569843] CPU: 2 PID: 1628 Comm: rmmod Kdump: loaded Tainted: G W 5.16.0-wt-ath+ #567<br /> [ 145.569898] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021<br /> [ 145.569956] RIP: 0010:ath11k_hal_srng_access_begin+0xb5/0x2b0 [ath11k]<br /> [ 145.570028] Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 ec 01 00 00 48 8b ab a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 b6 14 02 48 89 e8 83 e0 07 83 c0 03 45 85 ed 75 48 38 d0 7c 08<br /> [ 145.570089] RSP: 0018:ffffc900025d7ac0 EFLAGS: 00010246<br /> [ 145.570144] RAX: dffffc0000000000 RBX: ffff88814fca2dd8 RCX: 1ffffffff50cb455<br /> [ 145.570196] RDX: 0000000000000000 RSI: ffff88814fca2dd8 RDI: ffff88814fca2e80<br /> [ 145.570252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffa8659497<br /> [ 145.570329] R10: fffffbfff50cb292 R11: 0000000000000001 R12: ffff88814fca0000<br /> [ 145.570410] R13: 0000000000000000 R14: ffff88814fca2798 R15: ffff88814fca2dd8<br /> [ 145.570465] FS: 00007fa399988540(0000) GS:ffff888233e00000(0000) knlGS:0000000000000000<br /> [ 145.570519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 145.570571] CR2: 00007fa399b51421 CR3: 0000000137898002 CR4: 00000000003706e0<br /> [ 145.570623] Call Trace:<br /> [ 145.570675] <br /> [ 145.570727] ? ath11k_ce_tx_process_cb+0x34b/0x860 [ath11k]<br /> [ 145.570797] ath11k_ce_tx_process_cb+0x356/0x860 [ath11k]<br /> [ 145.570864] ? tasklet_init+0x150/0x150<br /> [ 145.570919] ? ath11k_ce_alloc_pipes+0x280/0x280 [ath11k]<br /> [ 145.570986] ? tasklet_clear_sched+0x42/0xe0<br /> [ 145.571042] ? tasklet_kill+0xe9/0x1b0<br /> [ 145.571095] ? tasklet_clear_sched+0xe0/0xe0<br /> [ 145.571148] ? irq_has_action+0x120/0x120<br /> [ 145.571202] ath11k_ce_cleanup_pipes+0x45a/0x580 [ath11k]<br /> [ 145.571270] ? ath11k_pci_stop+0x10e/0x170 [ath11k_pci]<br /> [ 145.571345] ath11k_core_stop+0x8a/0xc0 [ath11k]<br /> [ 145.571434] ath11k_core_deinit+0x9e/0x150 [ath11k]<br /> [ 145.571499] ath11k_pci_remove+0xd2/0x260 [ath11k_pci]<br /> [ 145.571553] pci_device_remove+0x9a/0x1c0<br /> [ 145.571605] __device_release_driver+0x332/0x660<br /> [ 145.571659] driver_detach+0x1e7/0x2c0<br /> [ 145.571712] bus_remove_driver+0xe2/0x2d0<br /> [ 145.571772] pci_unregister_driver+0x21/0x250<br /> [ 145.571826] __do_sys_delete_module+0x30a/0x4b0<br /> [ 145.571879] ? free_module+0xac0/0xac0<br /> [ 145.571933] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370<br /> [ 145.571986] ? syscall_enter_from_user_mode+0x1d/0x50<br /> [ 145.572039] ? lockdep_hardirqs_on+0x79/0x100<br /> [ 145.572097] do_syscall_64+0x3b/0x90<br /> [ 145.572153] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: fix kernel panic during unload/load ath11k modules<br /> <br /> Call netif_napi_del() from ath11k_ahb_free_ext_irq() to fix<br /> the following kernel panic when unload/load ath11k modules<br /> for few iterations.<br /> <br /> [ 971.201365] Unable to handle kernel paging request at virtual address 6d97a208<br /> [ 971.204227] pgd = 594c2919<br /> [ 971.211478] [6d97a208] *pgd=00000000<br /> [ 971.214120] Internal error: Oops: 5 [#1] PREEMPT SMP ARM<br /> [ 971.412024] CPU: 2 PID: 4435 Comm: insmod Not tainted 5.4.89 #0<br /> [ 971.434256] Hardware name: Generic DT based system<br /> [ 971.440165] PC is at napi_by_id+0x10/0x40<br /> [ 971.445019] LR is at netif_napi_add+0x160/0x1dc<br /> <br /> [ 971.743127] (napi_by_id) from [] (netif_napi_add+0x160/0x1dc)<br /> [ 971.751295] (netif_napi_add) from [] (ath11k_ahb_config_irq+0xf8/0x414 [ath11k_ahb])<br /> [ 971.759164] (ath11k_ahb_config_irq [ath11k_ahb]) from [] (ath11k_ahb_probe+0x40c/0x51c [ath11k_ahb])<br /> [ 971.768567] (ath11k_ahb_probe [ath11k_ahb]) from [] (platform_drv_probe+0x48/0x94)<br /> [ 971.779670] (platform_drv_probe) from [] (really_probe+0x1c8/0x450)<br /> [ 971.789389] (really_probe) from [] (driver_probe_device+0x15c/0x1b8)<br /> [ 971.797547] (driver_probe_device) from [] (device_driver_attach+0x44/0x60)<br /> [ 971.805795] (device_driver_attach) from [] (__driver_attach+0x124/0x140)<br /> [ 971.814822] (__driver_attach) from [] (bus_for_each_dev+0x58/0xa4)<br /> [ 971.823328] (bus_for_each_dev) from [] (bus_add_driver+0xf0/0x1e8)<br /> [ 971.831662] (bus_add_driver) from [] (driver_register+0xa8/0xf0)<br /> [ 971.839822] (driver_register) from [] (do_one_initcall+0x78/0x1ac)<br /> [ 971.847638] (do_one_initcall) from [] (do_init_module+0x54/0x200)<br /> [ 971.855968] (do_init_module) from [] (load_module+0x1e30/0x1ffc)<br /> [ 971.864126] (load_module) from [] (sys_init_module+0x134/0x17c)<br /> [ 971.871852] (sys_init_module) from [] (ret_fast_syscall+0x0/0x50)<br /> <br /> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00760-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: pci: fix crash on suspend if board file is not found<br /> <br /> Mario reported that the kernel was crashing on suspend if ath11k was not able<br /> to find a board file:<br /> <br /> [ 473.693286] PM: Suspending system (s2idle)<br /> [ 473.693291] printk: Suspending console(s) (use no_console_suspend to debug)<br /> [ 474.407787] BUG: unable to handle page fault for address: 0000000000002070<br /> [ 474.407791] #PF: supervisor read access in kernel mode<br /> [ 474.407794] #PF: error_code(0x0000) - not-present page<br /> [ 474.407798] PGD 0 P4D 0<br /> [ 474.407801] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 474.407805] CPU: 2 PID: 2350 Comm: kworker/u32:14 Tainted: G W 5.16.0 #248<br /> [...]<br /> [ 474.407868] Call Trace:<br /> [ 474.407870] <br /> [ 474.407874] ? _raw_spin_lock_irqsave+0x2a/0x60<br /> [ 474.407882] ? lock_timer_base+0x72/0xa0<br /> [ 474.407889] ? _raw_spin_unlock_irqrestore+0x29/0x3d<br /> [ 474.407892] ? try_to_del_timer_sync+0x54/0x80<br /> [ 474.407896] ath11k_dp_rx_pktlog_stop+0x49/0xc0 [ath11k]<br /> [ 474.407912] ath11k_core_suspend+0x34/0x130 [ath11k]<br /> [ 474.407923] ath11k_pci_pm_suspend+0x1b/0x50 [ath11k_pci]<br /> [ 474.407928] pci_pm_suspend+0x7e/0x170<br /> [ 474.407935] ? pci_pm_freeze+0xc0/0xc0<br /> [ 474.407939] dpm_run_callback+0x4e/0x150<br /> [ 474.407947] __device_suspend+0x148/0x4c0<br /> [ 474.407951] async_suspend+0x20/0x90<br /> dmesg-efi-164255130401001:<br /> Oops#1 Part1<br /> [ 474.407955] async_run_entry_fn+0x33/0x120<br /> [ 474.407959] process_one_work+0x220/0x3f0<br /> [ 474.407966] worker_thread+0x4a/0x3d0<br /> [ 474.407971] kthread+0x17a/0x1a0<br /> [ 474.407975] ? process_one_work+0x3f0/0x3f0<br /> [ 474.407979] ? set_kthread_struct+0x40/0x40<br /> [ 474.407983] ret_from_fork+0x22/0x30<br /> [ 474.407991] <br /> <br /> The issue here is that board file loading happens after ath11k_pci_probe()<br /> succesfully returns (ath11k initialisation happends asynchronously) and the<br /> suspend handler is still enabled, of course failing as ath11k is not properly<br /> initialised. Fix this by checking ATH11K_FLAG_QMI_FAIL during both suspend and<br /> resume.<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: svm range restore work deadlock when process exit<br /> <br /> kfd_process_notifier_release flush svm_range_restore_work<br /> which calls svm_range_list_lock_and_flush_work to flush deferred_list<br /> work, but if deferred_list work mmput release the last user, it will<br /> call exit_mmap -&gt; notifier_release, it is deadlock with below backtrace.<br /> <br /> Move flush svm_range_restore_work to kfd_process_wq_release to avoid<br /> deadlock. Then svm_range_restore_work take task-&gt;mm ref to avoid mm is<br /> gone while validating and mapping ranges to GPU.<br /> <br /> Workqueue: events svm_range_deferred_list_work [amdgpu]<br /> Call Trace:<br /> wait_for_completion+0x94/0x100<br /> __flush_work+0x12a/0x1e0<br /> __cancel_work_timer+0x10e/0x190<br /> cancel_delayed_work_sync+0x13/0x20<br /> kfd_process_notifier_release+0x98/0x2a0 [amdgpu]<br /> __mmu_notifier_release+0x74/0x1f0<br /> exit_mmap+0x170/0x200<br /> mmput+0x5d/0x130<br /> svm_range_deferred_list_work+0x104/0x230 [amdgpu]<br /> process_one_work+0x220/0x3c0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum: Guard against invalid local ports<br /> <br /> When processing events generated by the device&amp;#39;s firmware, the driver<br /> protects itself from events reported for non-existent local ports, but<br /> not for the CPU port (local port 0), which exists, but does not have all<br /> the fields as any local port.<br /> <br /> This can result in a NULL pointer dereference when trying access<br /> &amp;#39;struct mlxsw_sp_port&amp;#39; fields which are not initialized for CPU port.<br /> <br /> Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware")<br /> already handled such issue by bailing early when processing a PUDE event<br /> reported for the CPU port.<br /> <br /> Generalize the approach by moving the check to a common function and<br /> making use of it in all relevant places.