Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport<br /> <br /> [Why]<br /> Potential out of bounds access in dml2_calculate_rq_and_dlg_params()<br /> because the value of out_lowest_state_idx used as an index for FCLKChangeSupport<br /> array can be greater than 1.<br /> <br /> [How]<br /> Currently dml2 core specifies identical values for all FCLKChangeSupport<br /> elements. Always use index 0 in the condition to avoid out of bounds access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: check bo_va-&gt;bo is non-NULL before using it<br /> <br /> The call to radeon_vm_clear_freed might clear bo_va-&gt;bo, so<br /> we have to check it before dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bluetooth/l2cap: sync sock recv cb and release<br /> <br /> The problem occurs between the system call to close the sock and hci_rx_work,<br /> where the former releases the sock and the latter accesses it without lock protection.<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> sock_close hci_rx_work<br /> l2cap_sock_release hci_acldata_packet<br /> l2cap_sock_kill l2cap_recv_frame<br /> sk_free l2cap_conless_channel<br /> l2cap_sock_recv_cb<br /> <br /> If hci_rx_work processes the data that needs to be received before the sock is<br /> closed, then everything is normal; Otherwise, the work thread may access the<br /> released sock when receiving data.<br /> <br /> Add a chan mutex in the rx callback of the sock to achieve synchronization between<br /> the sock release and recv cb.<br /> <br /> Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: cancel all works upon hci_unregister_dev()<br /> <br /> syzbot is reporting that calling hci_release_dev() from hci_error_reset()<br /> due to hci_dev_put() from hci_error_reset() can cause deadlock at<br /> destroy_workqueue(), for hci_error_reset() is called from<br /> hdev-&gt;req_workqueue which destroy_workqueue() needs to flush.<br /> <br /> We need to make sure that hdev-&gt;{rx_work,cmd_work,tx_work} which are<br /> queued into hdev-&gt;workqueue and hdev-&gt;{power_on,error_reset} which are<br /> queued into hdev-&gt;req_workqueue are no longer running by the moment<br /> <br /> destroy_workqueue(hdev-&gt;workqueue);<br /> destroy_workqueue(hdev-&gt;req_workqueue);<br /> <br /> are called from hci_release_dev().<br /> <br /> Call cancel_work_sync() on these work items from hci_unregister_dev()<br /> as soon as hdev-&gt;list is removed from hci_dev_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/eeh: avoid possible crash when edev-&gt;pdev changes<br /> <br /> If a PCI device is removed during eeh_pe_report_edev(), edev-&gt;pdev<br /> will change and can cause a crash, hold the PCI rescan/remove lock<br /> while taking a copy of edev-&gt;pdev-&gt;bus.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Whitelist dtl slub object for copying to userspace<br /> <br /> Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*<br /> results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as<br /> shown below.<br /> <br /> kernel BUG at mm/usercopy.c:102!<br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc<br /> scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse<br /> CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85<br /> Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries<br /> NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8<br /> REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)<br /> MSR: 8000000000029033 CR: 2828220f XER: 0000000e<br /> CFAR: c0000000001fdc80 IRQMASK: 0<br /> [ ... GPRs omitted ... ]<br /> NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0<br /> LR [c0000000005d23d0] usercopy_abort+0x74/0xb0<br /> Call Trace:<br /> usercopy_abort+0x74/0xb0 (unreliable)<br /> __check_heap_object+0xf8/0x120<br /> check_heap_object+0x218/0x240<br /> __check_object_size+0x84/0x1a4<br /> dtl_file_read+0x17c/0x2c4<br /> full_proxy_read+0x8c/0x110<br /> vfs_read+0xdc/0x3a0<br /> ksys_read+0x84/0x144<br /> system_call_exception+0x124/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> --- interrupt: 3000 at 0x7fff81f3ab34<br /> <br /> Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")<br /> requires that only whitelisted areas in slab/slub objects can be copied to<br /> userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.<br /> Dtl contains hypervisor dispatch events which are expected to be read by<br /> privileged users. Hence mark this safe for user access.<br /> Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the<br /> entire object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: Add tx check to prevent skb leak<br /> <br /> Below is a summary of how the driver stores a reference to an skb during<br /> transmit:<br /> tx_buff[free_map[consumer_index]]-&gt;skb = new_skb;<br /> free_map[consumer_index] = IBMVNIC_INVALID_MAP;<br /> consumer_index ++;<br /> Where variable data looks like this:<br /> free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]<br /> consumer_index^<br /> tx_buff == [skb=null, skb=, skb=, skb=null, skb=null]<br /> <br /> The driver has checks to ensure that free_map[consumer_index] pointed to<br /> a valid index but there was no check to ensure that this index pointed<br /> to an unused/null skb address. So, if, by some chance, our free_map and<br /> tx_buff lists become out of sync then we were previously risking an<br /> skb memory leak. This could then cause tcp congestion control to stop<br /> sending packets, eventually leading to ETIMEDOUT.<br /> <br /> Therefore, add a conditional to ensure that the skb address is null. If<br /> not then warn the user (because this is still a bug that should be<br /> patched) and free the old pointer to prevent memleak/tcp problems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: topology: Fix references to freed memory<br /> <br /> Most users after parsing a topology file, release memory used by it, so<br /> having pointer references directly into topology file contents is wrong.<br /> Use devm_kmemdup(), to allocate memory as needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()<br /> <br /> Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().<br /> <br /> It looks up `stt` from tablefd, but then continues to use it after doing<br /> fdput() on the returned fd. After the fdput() the tablefd is free to be<br /> closed by another thread. The close calls kvm_spapr_tce_release() and<br /> then release_spapr_tce_table() (via call_rcu()) which frees `stt`.<br /> <br /> Although there are calls to rcu_read_lock() in<br /> kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent<br /> the UAF, because `stt` is used outside the locked regions.<br /> <br /> With an artifcial delay after the fdput() and a userspace program which<br /> triggers the race, KASAN detects the UAF:<br /> <br /> BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]<br /> Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505<br /> CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1<br /> Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV<br /> Call Trace:<br /> dump_stack_lvl+0xb4/0x108 (unreliable)<br /> print_report+0x2b4/0x6ec<br /> kasan_report+0x118/0x2b0<br /> __asan_load4+0xb8/0xd0<br /> kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]<br /> kvm_vfio_set_attr+0x524/0xac0 [kvm]<br /> kvm_device_ioctl+0x144/0x240 [kvm]<br /> sys_ioctl+0x62c/0x1810<br /> system_call_exception+0x190/0x440<br /> system_call_vectored_common+0x15c/0x2ec<br /> ...<br /> Freed by task 0:<br /> ...<br /> kfree+0xec/0x3e0<br /> release_spapr_tce_table+0xd4/0x11c [kvm]<br /> rcu_core+0x568/0x16a0<br /> handle_softirqs+0x23c/0x920<br /> do_softirq_own_stack+0x6c/0x90<br /> do_softirq_own_stack+0x58/0x90<br /> __irq_exit_rcu+0x218/0x2d0<br /> irq_exit+0x30/0x80<br /> arch_local_irq_restore+0x128/0x230<br /> arch_local_irq_enable+0x1c/0x30<br /> cpuidle_enter_state+0x134/0x5cc<br /> cpuidle_enter+0x6c/0xb0<br /> call_cpuidle+0x7c/0x100<br /> do_idle+0x394/0x410<br /> cpu_startup_entry+0x60/0x70<br /> start_secondary+0x3fc/0x410<br /> start_secondary_prolog+0x10/0x14<br /> <br /> Fix it by delaying the fdput() until `stt` is no longer in use, which<br /> is effectively the entire function. To keep the patch minimal add a call<br /> to fdput() at each of the existing return paths. Future work can convert<br /> the function to goto or __cleanup style cleanup.<br /> <br /> With the fix in place the test case no longer triggers the UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: wext: add extra SIOCSIWSCAN data check<br /> <br /> In &amp;#39;cfg80211_wext_siwscan()&amp;#39;, add extra check whether number of<br /> channels passed via &amp;#39;ioctl(sock, SIOCSIWSCAN, ...)&amp;#39; doesn&amp;#39;t exceed<br /> IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: Init the count variable in collecting hot-reset devices<br /> <br /> The count variable is used without initialization, it results in mistakes<br /> in the device counting and crashes the userspace if the get hot reset info<br /> path is triggered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix ufshcd_abort_one racing issue<br /> <br /> When ufshcd_abort_one is racing with the completion ISR, the completed tag<br /> of the request&amp;#39;s mq_hctx pointer will be set to NULL by ISR. Return<br /> success when request is completed by ISR because ufshcd_abort_one does not<br /> need to do anything.<br /> <br /> The racing flow is:<br /> <br /> Thread A<br /> ufshcd_err_handler step 1<br /> ...<br /> ufshcd_abort_one<br /> ufshcd_try_to_abort_task<br /> ufshcd_cmd_inflight(true) step 3<br /> ufshcd_mcq_req_to_hwq<br /> blk_mq_unique_tag<br /> rq-&gt;mq_hctx-&gt;queue_num step 5<br /> <br /> Thread B<br /> ufs_mtk_mcq_intr(cq complete ISR) step 2<br /> scsi_done<br /> ...<br /> __blk_mq_free_request<br /> rq-&gt;mq_hctx = NULL; step 4<br /> <br /> Below is KE back trace.<br /> ufshcd_try_to_abort_task: cmd at tag 41 not pending in the device.<br /> ufshcd_try_to_abort_task: cmd at tag=41 is cleared.<br /> Aborting tag 41 / CDB 0x28 succeeded<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194<br /> pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14<br /> lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40 [ufs_mediatek_mod_ise]<br /> do_mem_abort+0x58/0x118<br /> el1_abort+0x3c/0x5c<br /> el1h_64_sync_handler+0x54/0x90<br /> el1h_64_sync+0x68/0x6c<br /> blk_mq_unique_tag+0x8/0x14<br /> ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise]<br /> process_one_work+0x208/0x4fc<br /> worker_thread+0x228/0x438<br /> kthread+0x104/0x1d4<br /> ret_from_fork+0x10/0x20