Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: start MHI channel after endpoit creation<br /> <br /> MHI channel may generates event/interrupt right after enabling.<br /> It may leads to 2 race conditions issues.<br /> <br /> 1)<br /> Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check:<br /> <br /> if (!qdev || mhi_res-&gt;transaction_status)<br /> return;<br /> <br /> Because dev_set_drvdata(&amp;mhi_dev-&gt;dev, qdev) may be not performed at<br /> this moment. In this situation qrtr-ns will be unable to enumerate<br /> services in device.<br /> ---------------------------------------------------------------<br /> <br /> 2)<br /> Such event may come at the moment after dev_set_drvdata() and<br /> before qrtr_endpoint_register(). In this case kernel will panic with<br /> accessing wrong pointer at qcom_mhi_qrtr_dl_callback():<br /> <br /> rc = qrtr_endpoint_post(&amp;qdev-&gt;ep, mhi_res-&gt;buf_addr,<br /> mhi_res-&gt;bytes_xferd);<br /> <br /> Because endpoint is not created yet.<br /> --------------------------------------------------------------<br /> So move mhi_prepare_for_transfer_autoqueue after endpoint creation<br /> to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sun4i: dsi: Prevent underflow when computing packet sizes<br /> <br /> Currently, the packet overhead is subtracted using unsigned arithmetic.<br /> With a short sync pulse, this could underflow and wrap around to near<br /> the maximal u16 value. Fix this by using signed subtraction. The call to<br /> max() will correctly handle any negative numbers that are produced.<br /> <br /> Apply the same fix to the other timings, even though those subtractions<br /> are less likely to underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/ttm: don&amp;#39;t leak the ccs state<br /> <br /> The kernel only manages the ccs state with lmem-only objects, however<br /> the kernel should still take care not to leak the CCS state from the<br /> previous user.<br /> <br /> (cherry picked from commit 353819d85f87be46aeb9c1dd929d445a006fc6ec)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors()<br /> <br /> In this function, there are two refcount leak bugs:<br /> (1) when breaking out of for_each_endpoint_of_node(), we need call<br /> the of_node_put() for the &amp;#39;ep&amp;#39;;<br /> (2) we should call of_node_put() for the reference returned by<br /> of_graph_get_remote_port() when it is not used anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove()<br /> <br /> Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove<br /> paths") removed this clk_disable_unprepare()<br /> <br /> This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock<br /> handling on remove path") which removed this clk_disable_unprepare()<br /> because:<br /> "<br /> While unloading the dwmac-intel driver, clk_disable_unprepare() is<br /> being called twice in stmmac_dvr_remove() and<br /> intel_eth_pci_remove(). This causes kernel panic on the second call.<br /> "<br /> <br /> However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management<br /> for gmac driver") has updated stmmac_dvr_remove() which do not call<br /> clk_disable_unprepare() anymore.<br /> <br /> So this call should now be called from intel_eth_pci_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regions()<br /> <br /> If an error occurs in dsa_devlink_region_create(), then &amp;#39;priv-&gt;regions&amp;#39;<br /> array will be accessed by negative index &amp;#39;-1&amp;#39;.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix call trace with null VSI during VF reset<br /> <br /> During stress test with attaching and detaching VF from KVM and<br /> simultaneously changing VFs spoofcheck and trust there was a<br /> call trace in ice_reset_vf that VF&amp;#39;s VSI is null.<br /> <br /> [145237.352797] WARNING: CPU: 46 PID: 840629 at drivers/net/ethernet/intel/ice/ice_vf_lib.c:508 ice_reset_vf+0x3d6/0x410 [ice]<br /> [145237.352851] Modules linked in: ice(E) vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio iavf dm_mod xt_CHECKSUM xt_MASQUERADE<br /> xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun<br /> bridge stp llc sunrpc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iTCO_wdt iTC<br /> O_vendor_support irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl ipmi_si intel_cstate ipmi_devintf joydev intel_uncore m<br /> ei_me ipmi_msghandler i2c_i801 pcspkr mei lpc_ich ioatdma i2c_smbus acpi_pad acpi_power_meter ip_tables xfs libcrc32c i2c_algo_bit drm_sh<br /> mem_helper drm_kms_helper sd_mod t10_pi crc64_rocksoft syscopyarea crc64 sysfillrect sg sysimgblt fb_sys_fops drm i40e ixgbe ahci libahci<br /> libata crc32c_intel mdio dca wmi fuse [last unloaded: ice]<br /> [145237.352917] CPU: 46 PID: 840629 Comm: kworker/46:2 Tainted: G S W I E 5.19.0-rc6+ #24<br /> [145237.352921] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015<br /> [145237.352923] Workqueue: ice ice_service_task [ice]<br /> [145237.352948] RIP: 0010:ice_reset_vf+0x3d6/0x410 [ice]<br /> [145237.352984] Code: 30 ec f3 cc e9 28 fd ff ff 0f b7 4b 50 48 c7 c2 48 19 9c c0 4c 89 ee 48 c7 c7 30 fe 9e c0 e8 d1 21 9d cc 31 c0 e9 a<br /> 9 fe ff ff 0b b8 ea ff ff ff e9 c1 fc ff ff 0f 0b b8 fb ff ff ff e9 91 fe<br /> [145237.352987] RSP: 0018:ffffb453e257fdb8 EFLAGS: 00010246<br /> [145237.352990] RAX: ffff8bd0040181c0 RBX: ffff8be68db8f800 RCX: 0000000000000000<br /> [145237.352991] RDX: 000000000000ffff RSI: 0000000000000000 RDI: ffff8be68db8f800<br /> [145237.352993] RBP: ffff8bd0040181c0 R08: 0000000000001000 R09: ffff8bcfd520e000<br /> [145237.352995] R10: 0000000000000000 R11: 00008417b5ab0bc0 R12: 0000000000000005<br /> [145237.352996] R13: ffff8bcee061c0d0 R14: ffff8bd004019640 R15: 0000000000000000<br /> [145237.352998] FS: 0000000000000000(0000) GS:ffff8be5dfb00000(0000) knlGS:0000000000000000<br /> [145237.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [145237.353002] CR2: 00007fd81f651d68 CR3: 0000001a0fe10001 CR4: 00000000001726e0<br /> [145237.353003] Call Trace:<br /> [145237.353008] <br /> [145237.353011] ice_process_vflr_event+0x8d/0xb0 [ice]<br /> [145237.353049] ice_service_task+0x79f/0xef0 [ice]<br /> [145237.353074] process_one_work+0x1c8/0x390<br /> [145237.353081] ? process_one_work+0x390/0x390<br /> [145237.353084] worker_thread+0x30/0x360<br /> [145237.353087] ? process_one_work+0x390/0x390<br /> [145237.353090] kthread+0xe8/0x110<br /> [145237.353094] ? kthread_complete_and_exit+0x20/0x20<br /> [145237.353097] ret_from_fork+0x22/0x30<br /> [145237.353103] <br /> <br /> Remove WARN_ON() from check if VSI is null in ice_reset_vf.<br /> Add "VF is already removed\n" in dev_dbg().<br /> <br /> This WARN_ON() is unnecessary and causes call trace, despite that<br /> call trace, driver still works. There is no need for this warn<br /> because this piece of code is responsible for disabling VF&amp;#39;s Tx/Rx<br /> queues when VF is disabled, but when VF is already removed there<br /> is no need to do reset or disable queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: genl: fix error path memory leak in policy dumping<br /> <br /> If construction of the array of policies fails when recording<br /> non-first policy we need to unwind.<br /> <br /> netlink_policy_dump_add_policy() itself also needs fixing as<br /> it currently gives up on error without recording the allocated<br /> pointer in the pstate pointer.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: host: ohci-ppc-of: Fix refcount leak bug<br /> <br /> In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return<br /> a node pointer with refcount incremented. We should use of_node_put()<br /> when it is not used anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3 fix use-after-free at workaround 2<br /> <br /> BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xac<br /> <br /> cdns3_wa2_remove_old_request()<br /> {<br /> ...<br /> kfree(priv_req-&gt;request.buf);<br /> cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, &amp;priv_req-&gt;request);<br /> list_del_init(&amp;priv_req-&gt;list);<br /> ^^^ use after free<br /> ...<br /> }<br /> <br /> cdns3_gadget_ep_free_request() free the space pointed by priv_req,<br /> but priv_req is used in the following list_del_init().<br /> <br /> This patch move list_del_init() before cdns3_gadget_ep_free_request().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix use-after-free on amdgpu_bo_list mutex<br /> <br /> If amdgpu_cs_vm_handling returns r != 0, then it will unlock the<br /> bo_list_mutex inside the function amdgpu_cs_vm_handling and again on<br /> amdgpu_cs_parser_fini. This problem results in the following<br /> use-after-free problem:<br /> <br /> [ 220.280990] ------------[ cut here ]------------<br /> [ 220.281000] refcount_t: underflow; use-after-free.<br /> [ 220.281019] WARNING: CPU: 1 PID: 3746 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110<br /> [ 220.281029] ------------[ cut here ]------------<br /> [ 220.281415] CPU: 1 PID: 3746 Comm: chrome:cs0 Tainted: G W L ------- --- 5.20.0-0.rc0.20220812git7ebfc85e2cd7.10.fc38.x86_64 #1<br /> [ 220.281421] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022<br /> [ 220.281426] RIP: 0010:refcount_warn_saturate+0xba/0x110<br /> [ 220.281431] Code: 01 01 e8 79 4a 6f 00 0f 0b e9 42 47 a5 00 80 3d de<br /> 7e be 01 00 75 85 48 c7 c7 f8 98 8e 98 c6 05 ce 7e be 01 01 e8 56 4a<br /> 6f 00 0b e9 1f 47 a5 00 80 3d b9 7e be 01 00 0f 85 5e ff ff ff 48<br /> c7<br /> [ 220.281437] RSP: 0018:ffffb4b0d18d7a80 EFLAGS: 00010282<br /> [ 220.281443] RAX: 0000000000000026 RBX: 0000000000000003 RCX: 0000000000000000<br /> [ 220.281448] RDX: 0000000000000001 RSI: ffffffff988d06dc RDI: 00000000ffffffff<br /> [ 220.281452] RBP: 00000000ffffffff R08: 0000000000000000 R09: ffffb4b0d18d7930<br /> [ 220.281457] R10: 0000000000000003 R11: ffffa0672e2fffe8 R12: ffffa058ca360400<br /> [ 220.281461] R13: ffffa05846c50a18 R14: 00000000fffffe00 R15: 0000000000000003<br /> [ 220.281465] FS: 00007f82683e06c0(0000) GS:ffffa066e2e00000(0000) knlGS:0000000000000000<br /> [ 220.281470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 220.281475] CR2: 00003590005cc000 CR3: 00000001fca46000 CR4: 0000000000350ee0<br /> [ 220.281480] Call Trace:<br /> [ 220.281485] <br /> [ 220.281490] amdgpu_cs_ioctl+0x4e2/0x2070 [amdgpu]<br /> [ 220.281806] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]<br /> [ 220.282028] drm_ioctl_kernel+0xa4/0x150<br /> [ 220.282043] drm_ioctl+0x21f/0x420<br /> [ 220.282053] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]<br /> [ 220.282275] ? lock_release+0x14f/0x460<br /> [ 220.282282] ? _raw_spin_unlock_irqrestore+0x30/0x60<br /> [ 220.282290] ? _raw_spin_unlock_irqrestore+0x30/0x60<br /> [ 220.282297] ? lockdep_hardirqs_on+0x7d/0x100<br /> [ 220.282305] ? _raw_spin_unlock_irqrestore+0x40/0x60<br /> [ 220.282317] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]<br /> [ 220.282534] __x64_sys_ioctl+0x90/0xd0<br /> [ 220.282545] do_syscall_64+0x5b/0x80<br /> [ 220.282551] ? futex_wake+0x6c/0x150<br /> [ 220.282568] ? lock_is_held_type+0xe8/0x140<br /> [ 220.282580] ? do_syscall_64+0x67/0x80<br /> [ 220.282585] ? lockdep_hardirqs_on+0x7d/0x100<br /> [ 220.282592] ? do_syscall_64+0x67/0x80<br /> [ 220.282597] ? do_syscall_64+0x67/0x80<br /> [ 220.282602] ? lockdep_hardirqs_on+0x7d/0x100<br /> [ 220.282609] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 220.282616] RIP: 0033:0x7f8282a4f8bf<br /> [ 220.282639] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10<br /> 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00<br /> 0f 05 c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00<br /> 00<br /> [ 220.282644] RSP: 002b:00007f82683df410 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [ 220.282651] RAX: ffffffffffffffda RBX: 00007f82683df588 RCX: 00007f8282a4f8bf<br /> [ 220.282655] RDX: 00007f82683df4d0 RSI: 00000000c0186444 RDI: 0000000000000018<br /> [ 220.282659] RBP: 00007f82683df4d0 R08: 00007f82683df5e0 R09: 00007f82683df4b0<br /> [ 220.282663] R10: 00001d04000a0600 R11: 0000000000000246 R12: 00000000c0186444<br /> [ 220.282667] R13: 0000000000000018 R14: 00007f82683df588 R15: 0000000000000003<br /> [ 220.282689] <br /> [ 220.282693] irq event stamp: 6232311<br /> [ 220.282697] hardirqs last enabled at (6232319): [] __up_console_sem+0x5e/0x70<br /> [ 220.282704] hardirqs last disabled at (6232326): [] __up_console_sem+0x43/0x70<br /> [ 220.282709] softirqs last enabled at (6232072): [] __irq_exit_rcu+0xf9/0x170<br /> [ 220.282716] softirqs last disabled at (6232061): [