Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix memory leak<br /> <br /> [why]<br /> Resource release is needed on the error handling path<br /> to prevent memory leak.<br /> <br /> [how]<br /> Fix this by adding kfree on the error handling path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Fix queuing commands when HCI_UNREGISTER is set<br /> <br /> hci_cmd_sync_queue shall return an error if HCI_UNREGISTER flag has<br /> been set as that means hci_unregister_dev has been called so it will<br /> likely cause a uaf after the timeout as the hdev will be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj<br /> <br /> This issue takes place in an error path in<br /> amdgpu_cs_fence_to_handle_ioctl(). When `info-&gt;in.what` falls into<br /> default case, the function simply returns -EINVAL, forgetting to<br /> decrement the reference count of a dma_fence obj, which is bumped<br /> earlier by amdgpu_cs_get_fence(). This may result in reference count<br /> leaks.<br /> <br /> Fix it by decreasing the refcount of specific object before returning<br /> the error code.

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 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 /> 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 /> 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 /> 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. ]

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