Vulnerabilities

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 /> scsi: mpi3mr: Fix memory leaks<br /> <br /> Fix memory leaks related to operational reply queue&amp;#39;s memory segments which<br /> are not getting freed while unloading the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sprd: fix potential NULL dereference<br /> <br /> &amp;#39;drm&amp;#39; could be null in sprd_drm_shutdown, and drm_warn maybe dereference<br /> it, remove this warning log.<br /> <br /> <br /> v1 -&gt; v2:<br /> - Split checking platform_get_resource() return value to a separate patch<br /> - Use dev_warn() instead of removing the warning log

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: Fix frames flush failure caused by deadlock<br /> <br /> We are seeing below warnings:<br /> <br /> kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0<br /> kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0<br /> kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0<br /> <br /> this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work<br /> has no chance to run in 5 seconds.<br /> <br /> By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing<br /> ATH11K_FLUSH_TIMEOUT to 50 we get below warnings:<br /> <br /> kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds.<br /> kernel: [ 120.763169] Not tainted 5.10.90 #12<br /> kernel: [ 120.763177] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0<br /> kernel: [ 120.763201] Call Trace:<br /> kernel: [ 120.763214] __schedule+0x785/0x12fa<br /> kernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb<br /> kernel: [ 120.763242] schedule+0x7e/0xa1<br /> kernel: [ 120.763253] schedule_timeout+0x98/0xfe<br /> kernel: [ 120.763266] ? run_local_timers+0x4a/0x4a<br /> kernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a]<br /> kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e<br /> kernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]<br /> kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]<br /> kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]<br /> kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]<br /> kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]<br /> kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]<br /> kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]<br /> kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]<br /> kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]<br /> kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]<br /> kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2<br /> kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]<br /> kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]<br /> kernel: [ 120.763802] ? genl_rcv+0x36/0x36<br /> kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7<br /> kernel: [ 120.763829] genl_rcv+0x28/0x36<br /> kernel: [ 120.763840] netlink_unicast+0x179/0x24b<br /> kernel: [ 120.763854] netlink_sendmsg+0x393/0x401<br /> kernel: [ 120.763872] sock_sendmsg+0x72/0x76<br /> kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6<br /> kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2<br /> kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1<br /> kernel: [ 120.763940] __sys_sendmsg+0x85/0xbf<br /> kernel: [ 120.763956] do_syscall_64+0x43/0x55<br /> kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83<br /> kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> kernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83<br /> kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009<br /> kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000<br /> kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980<br /> kernel: [ 120.764032] R13: 00007ffe604<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req()<br /> <br /> In pm8001_chip_fw_flash_update_build(), if<br /> pm8001_chip_fw_flash_update_build() fails, the struct fw_control_ex<br /> allocated must be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: ralink: fix a refcount leak in ill_acc_of_setup()<br /> <br /> of_node_put(np) needs to be called when pdev == NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Free irq vectors in order for v3 HW<br /> <br /> If the driver probe fails to request the channel IRQ or fatal IRQ, the<br /> driver will free the IRQ vectors before freeing the IRQs in free_irq(),<br /> and this will cause a kernel BUG like this:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at drivers/pci/msi.c:369!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> Call trace:<br /> free_msi_irqs+0x118/0x13c<br /> pci_disable_msi+0xfc/0x120<br /> pci_free_irq_vectors+0x24/0x3c<br /> hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw]<br /> local_pci_probe+0x44/0xb0<br /> work_for_cpu_fn+0x20/0x34<br /> process_one_work+0x1d0/0x340<br /> worker_thread+0x2e0/0x460<br /> kthread+0x180/0x190<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace b88990335b610c11 ]---<br /> <br /> So we use devm_add_action() to control the order in which we free the<br /> vectors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix task leak in pm8001_send_abort_all()<br /> <br /> In pm8001_send_abort_all(), make sure to free the allocated sas task<br /> if pm8001_tag_alloc() or pm8001_mpi_build_cmd() fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix tag leaks on error<br /> <br /> In pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),<br /> pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing calls<br /> to pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()<br /> fails.<br /> <br /> Similarly, in pm8001_exec_internal_task_abort(), if the chip -&gt;task_abort<br /> method fails, the tag allocated for the abort request task must be<br /> freed. Add the missing call to pm8001_tag_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm ioctl: prevent potential spectre v1 gadget<br /> <br /> It appears like cmd could be a Spectre v1 gadget as it&amp;#39;s supplied by a<br /> user and used as an array index. Prevent the contents of kernel memory<br /> from being leaked to userspace via speculative execution by using<br /> array_index_nospec.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mce: Work around an erratum on fast string copy instructions<br /> <br /> A rare kernel panic scenario can happen when the following conditions<br /> are met due to an erratum on fast string copy instructions:<br /> <br /> 1) An uncorrected error.<br /> 2) That error must be in first cache line of a page.<br /> 3) Kernel must execute page_copy from the page immediately before that<br /> page.<br /> <br /> The fast string copy instructions ("REP; MOVS*") could consume an<br /> uncorrectable memory error in the cache line _right after_ the desired<br /> region to copy and raise an MCE.<br /> <br /> Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast string<br /> copy and will avoid such spurious machine checks. However, that is less<br /> preferable due to the permanent performance impact. Considering memory<br /> poison is rare, it&amp;#39;s desirable to keep fast string copy enabled until an<br /> MCE is seen.<br /> <br /> Intel has confirmed the following:<br /> 1. The CPU erratum of fast string copy only applies to Skylake,<br /> Cascade Lake and Cooper Lake generations.<br /> <br /> Directly return from the MCE handler:<br /> 2. Will result in complete execution of the "REP; MOVS*" with no data<br /> loss or corruption.<br /> 3. Will not result in another MCE firing on the next poisoned cache line<br /> due to "REP; MOVS*".<br /> 4. Will resume execution from a correct point in code.<br /> 5. Will result in the same instruction that triggered the MCE firing a<br /> second MCE immediately for any other software recoverable data fetch<br /> errors.<br /> 6. Is not safe without disabling the fast string copy, as the next fast<br /> string copy of the same buffer on the same CPU would result in a PANIC<br /> MCE.<br /> <br /> This should mitigate the erratum completely with the only caveat that<br /> the fast string copy is disabled on the affected hyper thread thus<br /> performance degradation.<br /> <br /> This is still better than the OS crashing on MCEs raised on an<br /> irrelevant process due to "REP; MOVS*&amp;#39; accesses in a kernel context,<br /> e.g., copy_page.<br /> <br /> <br /> Injected errors on 1st cache line of 8 anonymous pages of process<br /> &amp;#39;proc1&amp;#39; and observed MCE consumption from &amp;#39;proc2&amp;#39; with no panic<br /> (directly returned).<br /> <br /> Without the fix, the host panicked within a few minutes on a<br /> random &amp;#39;proc2&amp;#39; process due to kernel access from copy_page.<br /> <br /> [ bp: Fix comment style + touch ups, zap an unlikely(), improve the<br /> quirk function&amp;#39;s readability. ]