Vulnerabilities

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.

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix invalid algorithm for encoded extents<br /> <br /> The current algorithm sanity checks do not properly apply to new<br /> encoded extents.<br /> <br /> Unify the algorithm check with Z_EROFS_COMPRESSION(_RUNTIME)_MAX<br /> and ensure consistency with sbi-&gt;available_compr_algs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: implement NETDEV_UNREGISTER notification handler<br /> <br /> syzbot is reporting<br /> <br /> unregister_netdevice: waiting for vcan0 to become free. Usage count = 2<br /> <br /> problem, for j1939 protocol did not have NETDEV_UNREGISTER notification<br /> handler for undoing changes made by j1939_sk_bind().<br /> <br /> Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct<br /> callback") expects that a call to j1939_priv_put() can be unconditionally<br /> delayed until j1939_sk_sock_destruct() is called. But we need to call<br /> j1939_priv_put() against an extra ref held by j1939_sk_bind() call<br /> (as a part of undoing changes made by j1939_sk_bind()) as soon as<br /> NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()<br /> is called via j1939_sk_release()). Otherwise, the extra ref on "struct<br /> j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from<br /> dropping the usage count to 1; making it impossible for<br /> unregister_netdevice() to continue.<br /> <br /> [mkl: remove space in front of label]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genetlink: fix genl_bind() invoking bind() after -EPERM<br /> <br /> Per family bind/unbind callbacks were introduced to allow families<br /> to track multicast group consumer presence, e.g. to start or stop<br /> producing events depending on listeners.<br /> <br /> However, in genl_bind() the bind() callback was invoked even if<br /> capability checks failed and ret was set to -EPERM. This means that<br /> callbacks could run on behalf of unauthorized callers while the<br /> syscall still returned failure to user space.<br /> <br /> Fix this by only invoking bind() after "if (ret) break;" check<br /> i.e. after permission checks have succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pcmcia: Add error handling for add_interval() in do_validate_mem()<br /> <br /> In the do_validate_mem(), the call to add_interval() does not<br /> handle errors. If kmalloc() fails in add_interval(), it could<br /> result in a null pointer being inserted into the linked list,<br /> leading to illegal memory access when sub_interval() is called<br /> next.<br /> <br /> This patch adds an error handling for the add_interval(). If<br /> add_interval() returns an error, the function will return early<br /> with the error code.