Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix ufshcd_clear_cmd racing issue<br /> <br /> When ufshcd_clear_cmd 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 the ISR. And<br /> ufshcd_clear_cmd&amp;#39;s call to ufshcd_mcq_req_to_hwq will get NULL pointer KE.<br /> Return success when the request is completed by ISR because sq does not<br /> need cleanup.<br /> <br /> The racing flow is:<br /> <br /> Thread A<br /> ufshcd_err_handler step 1<br /> ufshcd_try_to_abort_task<br /> ufshcd_cmd_inflight(true) step 3<br /> ufshcd_clear_cmd<br /> ...<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 /> <br /> ufshcd_try_to_abort_task: cmd pending in the device. tag = 6<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194<br /> pc : [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14<br /> lr : [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc [ufs_mediatek_mod_ise]<br /> Workqueue: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise]<br /> Call trace:<br /> dump_backtrace+0xf8/0x148<br /> show_stack+0x18/0x24<br /> dump_stack_lvl+0x60/0x7c<br /> dump_stack+0x18/0x3c<br /> mrdump_common_die+0x24c/0x398 [mrdump]<br /> ipanic_die+0x20/0x34 [mrdump]<br /> notify_die+0x80/0xd8<br /> die+0x94/0x2b8<br /> __do_kernel_fault+0x264/0x298<br /> do_page_fault+0xa4/0x4b8<br /> do_translation_fault+0x38/0x54<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_clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise]<br /> ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise]<br /> ufshcd_err_handler+0xa7c/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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix XDP program unloading while removing the driver<br /> <br /> The commit 6533e558c650 ("i40e: Fix reset path while removing<br /> the driver") introduced a new PF state "__I40E_IN_REMOVE" to block<br /> modifying the XDP program while the driver is being removed.<br /> Unfortunately, such a change is useful only if the ".ndo_bpf()"<br /> callback was called out of the rmmod context because unloading the<br /> existing XDP program is also a part of driver removing procedure.<br /> In other words, from the rmmod context the driver is expected to<br /> unload the XDP program without reporting any errors. Otherwise,<br /> the kernel warning with callstack is printed out to dmesg.<br /> <br /> Example failing scenario:<br /> 1. Load the i40e driver.<br /> 2. Load the XDP program.<br /> 3. Unload the i40e driver (using "rmmod" command).<br /> <br /> The example kernel warning log:<br /> <br /> [ +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870<br /> [...]<br /> [ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870<br /> [...]<br /> [ +0.002726] Call Trace:<br /> [ +0.002457] <br /> [ +0.002119] ? __warn+0x80/0x120<br /> [ +0.003245] ? unregister_netdevice_many_notify+0x7a9/0x870<br /> [ +0.005586] ? report_bug+0x164/0x190<br /> [ +0.003678] ? handle_bug+0x3c/0x80<br /> [ +0.003503] ? exc_invalid_op+0x17/0x70<br /> [ +0.003846] ? asm_exc_invalid_op+0x1a/0x20<br /> [ +0.004200] ? unregister_netdevice_many_notify+0x7a9/0x870<br /> [ +0.005579] ? unregister_netdevice_many_notify+0x3cc/0x870<br /> [ +0.005586] unregister_netdevice_queue+0xf7/0x140<br /> [ +0.004806] unregister_netdev+0x1c/0x30<br /> [ +0.003933] i40e_vsi_release+0x87/0x2f0 [i40e]<br /> [ +0.004604] i40e_remove+0x1a1/0x420 [i40e]<br /> [ +0.004220] pci_device_remove+0x3f/0xb0<br /> [ +0.003943] device_release_driver_internal+0x19f/0x200<br /> [ +0.005243] driver_detach+0x48/0x90<br /> [ +0.003586] bus_remove_driver+0x6d/0xf0<br /> [ +0.003939] pci_unregister_driver+0x2e/0xb0<br /> [ +0.004278] i40e_exit_module+0x10/0x5f0 [i40e]<br /> [ +0.004570] __do_sys_delete_module.isra.0+0x197/0x310<br /> [ +0.005153] do_syscall_64+0x85/0x170<br /> [ +0.003684] ? syscall_exit_to_user_mode+0x69/0x220<br /> [ +0.004886] ? do_syscall_64+0x95/0x170<br /> [ +0.003851] ? exc_page_fault+0x7e/0x180<br /> [ +0.003932] entry_SYSCALL_64_after_hwframe+0x71/0x79<br /> [ +0.005064] RIP: 0033:0x7f59dc9347cb<br /> [ +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 00 f7 d8 64 89 01 48 83<br /> c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f<br /> 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48<br /> [ +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0<br /> [ +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb<br /> [ +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748<br /> [ +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000<br /> [ +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000<br /> [ +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000<br /> [ +0.007151] <br /> [ +0.002204] ---[ end trace 0000000000000000 ]---<br /> <br /> Fix this by checking if the XDP program is being loaded or unloaded.<br /> Then, block only loading a new program while "__I40E_IN_REMOVE" is set.<br /> Also, move testing "__I40E_IN_REMOVE" flag to the beginning of XDP_SETUP<br /> callback to avoid unnecessary operations and checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skmsg: Skip zero length skb in sk_msg_recvmsg<br /> <br /> When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch<br /> platform, the following kernel panic occurs:<br /> <br /> [...]<br /> Oops[#1]:<br /> CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18<br /> Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018<br /> ... ...<br /> ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560<br /> ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0<br /> CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> PRMD: 0000000c (PPLV0 +PIE +PWE)<br /> EUEN: 00000007 (+FPE +SXE +ASXE -BTE)<br /> ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> BADV: 0000000000000040<br /> PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)<br /> Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack<br /> Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)<br /> Stack : ...<br /> Call Trace:<br /> [] copy_page_to_iter+0x74/0x1c0<br /> [] sk_msg_recvmsg+0x120/0x560<br /> [] tcp_bpf_recvmsg_parser+0x170/0x4e0<br /> [] inet_recvmsg+0x54/0x100<br /> [] sock_recvmsg+0x7c/0xe0<br /> [] __sys_recvfrom+0x108/0x1c0<br /> [] sys_recvfrom+0x1c/0x40<br /> [] do_syscall+0x8c/0xc0<br /> [] handle_syscall+0xc4/0x160<br /> Code: ...<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception<br /> Kernel relocated by 0x3510000<br /> .text @ 0x9000000003710000<br /> .data @ 0x9000000004d70000<br /> .bss @ 0x9000000006469400<br /> ---[ end Kernel panic - not syncing: Fatal exception ]---<br /> [...]<br /> <br /> This crash happens every time when running sockmap_skb_verdict_shutdown<br /> subtest in sockmap_basic.<br /> <br /> This crash is because a NULL pointer is passed to page_address() in the<br /> sk_msg_recvmsg(). Due to the different implementations depending on the<br /> architecture, page_address(NULL) will trigger a panic on Loongarch<br /> platform but not on x86 platform. So this bug was hidden on x86 platform<br /> for a while, but now it is exposed on Loongarch platform. The root cause<br /> is that a zero length skb (skb-&gt;len == 0) was put on the queue.<br /> <br /> This zero length skb is a TCP FIN packet, which was sent by shutdown(),<br /> invoked in test_sockmap_skb_verdict_shutdown():<br /> <br /> shutdown(p1, SHUT_WR);<br /> <br /> In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no<br /> page is put to this sge (see sg_set_page in sg_set_page), but this empty<br /> sge is queued into ingress_msg list.<br /> <br /> And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by<br /> sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it<br /> to kmap_local_page() and to page_address(), then kernel panics.<br /> <br /> To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),<br /> if copy is zero, that means it&amp;#39;s a zero length skb, skip invoking<br /> copy_page_to_iter(). We are using the EFAULT return triggered by<br /> copy_page_to_iter to check for is_fin in tcp_bpf.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> filelock: fix potential use-after-free in posix_lock_inode<br /> <br /> Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().<br /> The request pointer had been changed earlier to point to a lock entry<br /> that was added to the inode&amp;#39;s list. However, before the tracepoint could<br /> fire, another task raced in and freed that lock.<br /> <br /> Fix this by moving the tracepoint inside the spinlock, which should<br /> ensure that this doesn&amp;#39;t happen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: cyclic allocation of msg_id to avoid reuse<br /> <br /> Reusing the msg_id after a maliciously completed reopen request may cause<br /> a read request to remain unprocessed and result in a hung, as shown below:<br /> <br /> t1 | t2 | t3<br /> -------------------------------------------------<br /> cachefiles_ondemand_select_req<br /> cachefiles_ondemand_object_is_close(A)<br /> cachefiles_ondemand_set_object_reopening(A)<br /> queue_work(fscache_object_wq, &amp;info-&gt;work)<br /> ondemand_object_worker<br /> cachefiles_ondemand_init_object(A)<br /> cachefiles_ondemand_send_req(OPEN)<br /> // get msg_id 6<br /> wait_for_completion(&amp;req_A-&gt;done)<br /> cachefiles_ondemand_daemon_read<br /> // read msg_id 6 req_A<br /> cachefiles_ondemand_get_fd<br /> copy_to_user<br /> // Malicious completion msg_id 6<br /> copen 6,-1<br /> cachefiles_ondemand_copen<br /> complete(&amp;req_A-&gt;done)<br /> // will not set the object to close<br /> // because ondemand_id &amp;&amp; fd is valid.<br /> <br /> // ondemand_object_worker() is done<br /> // but the object is still reopening.<br /> <br /> // new open req_B<br /> cachefiles_ondemand_init_object(B)<br /> cachefiles_ondemand_send_req(OPEN)<br /> // reuse msg_id 6<br /> process_open_req<br /> copen 6,A.size<br /> // The expected failed copen was executed successfully<br /> <br /> Expect copen to fail, and when it does, it closes fd, which sets the<br /> object to close, and then close triggers reopen again. However, due to<br /> msg_id reuse resulting in a successful copen, the anonymous fd is not<br /> closed until the daemon exits. Therefore read requests waiting for reopen<br /> to complete may trigger hung task.<br /> <br /> To avoid this issue, allocate the msg_id cyclically to avoid reusing the<br /> msg_id for a very short duration of time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: wait for ondemand_object_worker to finish when dropping object<br /> <br /> When queuing ondemand_object_worker() to re-open the object,<br /> cachefiles_object is not pinned. The cachefiles_object may be freed when<br /> the pending read request is completed intentionally and the related<br /> erofs is umounted. If ondemand_object_worker() runs after the object is<br /> freed, it will incur use-after-free problem as shown below.<br /> <br /> process A processs B process C process D<br /> <br /> cachefiles_ondemand_send_req()<br /> // send a read req X<br /> // wait for its completion<br /> <br /> // close ondemand fd<br /> cachefiles_ondemand_fd_release()<br /> // set object as CLOSE<br /> <br /> cachefiles_ondemand_daemon_read()<br /> // set object as REOPENING<br /> queue_work(fscache_wq, &amp;info-&gt;ondemand_work)<br /> <br /> // close /dev/cachefiles<br /> cachefiles_daemon_release<br /> cachefiles_flush_reqs<br /> complete(&amp;req-&gt;done)<br /> <br /> // read req X is completed<br /> // umount the erofs fs<br /> cachefiles_put_object()<br /> // object will be freed<br /> cachefiles_ondemand_deinit_obj_info()<br /> kmem_cache_free(object)<br /> // both info and object are freed<br /> ondemand_object_worker()<br /> <br /> When dropping an object, it is no longer necessary to reopen the object,<br /> so use cancel_work_sync() to cancel or wait for ondemand_object_worker()<br /> to finish.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: prevent derefencing NULL ptr in pfn_section_valid()<br /> <br /> Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing<br /> memory_section-&gt;usage") changed pfn_section_valid() to add a READ_ONCE()<br /> call around "ms-&gt;usage" to fix a race with section_deactivate() where<br /> ms-&gt;usage can be cleared. The READ_ONCE() call, by itself, is not enough<br /> to prevent NULL pointer dereference. We need to check its value before<br /> dereferencing it.