Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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")

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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. ]

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: microchip-core-qspi: stop checking viability of op-&gt;max_freq in supports_op callback<br /> <br /> In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem<br /> operation frequency switches") the logic for checking the viability of<br /> op-&gt;max_freq in mchp_coreqspi_setup_clock() was copied into<br /> mchp_coreqspi_supports_op(). Unfortunately, op-&gt;max_freq is not valid<br /> when this function is called during probe but is instead zero.<br /> Accordingly, baud_rate_val is calculated to be INT_MAX due to division<br /> by zero, causing probe of the attached memory device to fail.<br /> <br /> Seemingly spi-microchip-core-qspi was the only driver that had such a<br /> modification made to its supports_op callback when the per_op_freq<br /> capability was added, so just remove it to restore prior functionality.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: fix incorrect map used in eee linkmode<br /> <br /> incorrectly used ixgbe_lp_map in loops intended to populate the<br /> supported and advertised EEE linkmode bitmaps based on ixgbe_ls_map.<br /> This results in incorrect bit setting and potential out-of-bounds<br /> access, since ixgbe_lp_map and ixgbe_ls_map have different sizes<br /> and purposes.<br /> <br /> ixgbe_lp_map[i] -&gt; ixgbe_ls_map[i]<br /> <br /> Use ixgbe_ls_map for supported and advertised linkmodes, and keep<br /> ixgbe_lp_map usage only for link partner (lp_advertised) mapping.