Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: char: Avoid double destroy of default endpoint<br /> <br /> The rpmsg_dev_remove() in rpmsg_core is the place for releasing<br /> this default endpoint.<br /> <br /> So need to avoid destroying the default endpoint in<br /> rpmsg_chrdev_eptdev_destroy(), this should be the same as<br /> rpmsg_eptdev_release(). Otherwise there will be double destroy<br /> issue that ept-&gt;refcount report warning:<br /> <br /> refcount_t: underflow; use-after-free.<br /> <br /> Call trace:<br /> refcount_warn_saturate+0xf8/0x150<br /> virtio_rpmsg_destroy_ept+0xd4/0xec<br /> rpmsg_dev_remove+0x60/0x70<br /> <br /> The issue can be reproduced by stopping remoteproc before<br /> closing the /dev/rpmsgX.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()<br /> <br /> When executing SMP task failed, the smp_execute_task_sg() calls del_timer()<br /> to delete "slow_task-&gt;timer". However, if the timer handler<br /> sas_task_internal_timedout() is running, the del_timer() in<br /> smp_execute_task_sg() will not stop it and a UAF will happen. The process<br /> is shown below:<br /> <br /> (thread 1) | (thread 2)<br /> smp_execute_task_sg() | sas_task_internal_timedout()<br /> ... |<br /> del_timer() |<br /> ... | ...<br /> sas_free_task(task) |<br /> kfree(task-&gt;slow_task) //FREE|<br /> | task-&gt;slow_task-&gt;... //USE<br /> <br /> Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure<br /> the timer handler have finished before the "task-&gt;slow_task" is<br /> deallocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()<br /> <br /> There is an use-after-free reported by KASAN:<br /> <br /> BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82<br /> Read of size 1 at addr ffff888112afc460 by task modprobe/2111<br /> CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> Call Trace:<br /> <br /> kasan_report+0xae/0xe0<br /> acpi_ut_remove_reference+0x3b/0x82<br /> acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5<br /> acpi_ds_store_object_to_local+0x15d/0x3a0<br /> acpi_ex_store+0x78d/0x7fd<br /> acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b<br /> acpi_ps_parse_aml+0x217/0x8d5<br /> ...<br /> <br /> <br /> The root cause of the problem is that the acpi_operand_object<br /> is freed when acpi_ut_walk_package_tree() fails in<br /> acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in<br /> acpi_ut_copy_iobject_to_iobject(). The problem was introduced<br /> by "8aa5e56eeb61" commit, this commit is to fix memory leak in<br /> acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove<br /> operation, lead to "acpi_operand_object" used after free.<br /> <br /> Fix it by removing acpi_ut_remove_reference() in<br /> acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()<br /> is called to copy an internal package object into another internal<br /> package object, when it fails, the memory of acpi_operand_object<br /> should be freed by the caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: resource leaks at mt7921_check_offload_capability()<br /> <br /> Fixed coverity issue with resource leaks at variable "fw" going out of<br /> scope leaks the storage it points to mt7921_check_offload_capability().<br /> <br /> Addresses-Coverity-ID: 1527806 ("Resource leaks")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly<br /> <br /> When an extended state component is not present in fpstate, but in init<br /> state, the function copies from init_fpstate via copy_feature().<br /> <br /> But, dynamic states are not present in init_fpstate because of all-zeros<br /> init states. Then retrieving them from init_fpstate will explode like this:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> RIP: 0010:memcpy_erms+0x6/0x10<br /> ? __copy_xstate_to_uabi_buf+0x381/0x870<br /> fpu_copy_guest_fpstate_to_uabi+0x28/0x80<br /> kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm]<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> ? vmx_vcpu_put+0x2e/0x260 [kvm_intel]<br /> kvm_vcpu_ioctl+0xea/0x6b0 [kvm]<br /> ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm]<br /> ? __fget_light+0xd4/0x130<br /> __x64_sys_ioctl+0xe3/0x910<br /> ? debug_smp_processor_id+0x17/0x20<br /> ? fpregs_assert_state_consistent+0x27/0x50<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Adjust the &amp;#39;mask&amp;#39; to zero out the userspace buffer for the features that<br /> are not available both from fpstate and from init_fpstate.<br /> <br /> The dynamic features depend on the compacted XSAVE format. Ensure it is<br /> enabled before reading XCOMP_BV in init_fpstate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix UBSAN shift-out-of-bounds warning<br /> <br /> If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up<br /> doing a shift operation where the number of bits shifted equals<br /> number of bits in the operand. This behaviour is undefined.<br /> <br /> Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the<br /> count is &gt;= number of bits in the operand.<br /> <br /> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472

DX Unified Infrastructure Management (Nimsoft/UIM) and below contains an improper ACL handling vulnerability in the robot (controller) component. A remote attacker can execute commands, read from, or write to the target system.

Deserialization of untrusted data in python in pyfory versions 0.12.0 through 0.12.2, or the legacy pyfury versions from 0.1.0 through 0.10.3: allows arbitrary code execution. An application is vulnerable if it reads pyfory serialized data from untrusted sources. An attacker can craft a data stream that selects pickle-fallback serializer during deserialization, leading to the execution of `pickle.loads`, which is vulnerable to remote code execution.<br /> <br /> Users are recommended to upgrade to pyfory version 0.12.3 or later, which has removed pickle fallback serializer and thus fixes this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix race condition validating r_parent before applying state<br /> <br /> Add validation to ensure the cached parent directory inode matches the<br /> directory info in MDS replies. This prevents client-side race conditions<br /> where concurrent operations (e.g. rename) cause r_parent to become stale<br /> between request initiation and reply processing, which could lead to<br /> applying state changes to incorrect directory inodes.<br /> <br /> [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to<br /> move CEPH_CAP_PIN reference when r_parent is updated:<br /> <br /> When the parent directory lock is not held, req-&gt;r_parent can become<br /> stale and is updated to point to the correct inode. However, the<br /> associated CEPH_CAP_PIN reference was not being adjusted. The<br /> CEPH_CAP_PIN is a reference on an inode that is tracked for<br /> accounting purposes. Moving this pin is important to keep the<br /> accounting balanced. When the pin was not moved from the old parent<br /> to the new one, it created two problems: The reference on the old,<br /> stale parent was never released, causing a reference leak.<br /> A reference for the new parent was never acquired, creating the risk<br /> of a reference underflow later in ceph_mdsc_release_request(). This<br /> patch corrects the logic by releasing the pin from the old parent and<br /> acquiring it for the new parent when r_parent is switched. This<br /> ensures reference accounting stays balanced. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: rtl9300: ensure data length is within supported range<br /> <br /> Add an explicit check for the xfer length to &amp;#39;rtl9300_i2c_config_xfer&amp;#39;<br /> to ensure the data length isn&amp;#39;t within the supported range. In<br /> particular a data length of 0 is not supported by the hardware and<br /> causes unintended or destructive behaviour.<br /> <br /> This limitation becomes obvious when looking at the register<br /> documentation [1]. 4 bits are reserved for DATA_WIDTH and the value<br /> of these 4 bits is used as N + 1, allowing a data length range of<br /> 1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: fix linked list corruption<br /> <br /> Never leave scheduled wcid entries on the temporary on-stack list

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: add missing check for rx wcid entries<br /> <br /> Non-station wcid entries must not be passed to the rx functions.<br /> In case of the global wcid entry, it could even lead to corruption in the wcid<br /> array due to pointer being casted to struct mt7996_sta_link using container_of.