CVE-2022-49132

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