Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/sclp: Fix sclp_init() cleanup on failure<br /> <br /> If sclp_init() fails it only partially cleans up: if there are multiple<br /> failing calls to sclp_init() sclp_state_change_event will be added several<br /> times to sclp_reg_list, which results in the following warning:<br /> <br /> ------------[ cut here ]------------<br /> list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.<br /> WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3<br /> Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)<br /> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3<br /> ...<br /> Call Trace:<br /> [] __list_add_valid_or_report+0xe2/0xf8<br /> ([] __list_add_valid_or_report+0xde/0xf8)<br /> [] sclp_init+0x40e/0x450<br /> [] do_one_initcall+0x42/0x1e0<br /> [] do_initcalls+0x126/0x150<br /> [] kernel_init_freeable+0x1ba/0x1f8<br /> [] kernel_init+0x2e/0x180<br /> [] __ret_from_fork+0x3c/0x60<br /> [] ret_from_fork+0xa/0x30<br /> <br /> Fix this by removing sclp_state_change_event from sclp_reg_list when<br /> sclp_init() fails.

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