Vulnerabilities

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

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 /> 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 /> staging: vchiq_arm: Avoid NULL ptr deref in vchiq_dump_platform_instances<br /> <br /> vchiq_get_state() can return a NULL pointer. So handle this cases and<br /> avoid a NULL pointer derefence in vchiq_dump_platform_instances.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix memory leak in ceph_readdir when note_last_dentry returns error<br /> <br /> Reset the last_readdir at the same time, and add a comment explaining<br /> why we don&amp;#39;t free last_readdir when dir_emit returns false.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: Fix memory leaks on probe<br /> <br /> Handle the error branches to free memory where required.<br /> <br /> Addresses-Coverity-ID: 1491825 ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix inode reference leakage in ceph_get_snapdir()<br /> <br /> The ceph_get_inode() will search for or insert a new inode into the<br /> hash for the given vino, and return a reference to it. If new is<br /> non-NULL, its reference is consumed.<br /> <br /> We should release the reference when in error handing cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: revisit gc autotuning<br /> <br /> as of commit 4608fdfc07e1<br /> ("netfilter: conntrack: collect all entries in one cycle")<br /> conntrack gc was changed to run every 2 minutes.<br /> <br /> On systems where conntrack hash table is set to large value, most evictions<br /> happen from gc worker rather than the packet path due to hash table<br /> distribution.<br /> <br /> This causes netlink event overflows when events are collected.<br /> <br /> This change collects average expiry of scanned entries and<br /> reschedules to the average remaining value, within 1 to 60 second interval.<br /> <br /> To avoid event overflows, reschedule after each bucket and add a<br /> limit for both run time and number of evictions per run.<br /> <br /> If more entries have to be evicted, reschedule and restart 1 jiffy<br /> into the future.