Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()<br /> <br /> The acpi_power_meter driver&amp;#39;s .notify() callback function,<br /> acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock<br /> that is also acquired by callbacks in sysfs attributes of the device<br /> being unregistered which is prone to deadlocks between sysfs access and<br /> device removal.<br /> <br /> Address this by moving the hwmon device removal in<br /> acpi_power_meter_notify() outside the lock in question, but notice<br /> that doing it alone is not sufficient because two concurrent<br /> METER_NOTIFY_CONFIG notifications may be attempting to remove the<br /> same device at the same time. To prevent that from happening, add a<br /> new lock serializing the execution of the switch () statement in<br /> acpi_power_meter_notify(). For simplicity, it is a static mutex<br /> which should not be a problem from the performance perspective.<br /> <br /> The new lock also allows the hwmon_device_register_with_info()<br /> in acpi_power_meter_notify() to be called outside the inner lock<br /> because it prevents the other notifications handled by that function<br /> from manipulating the "resource" object while the hwmon device based<br /> on it is being registered. The sending of ACPI netlink messages from<br /> acpi_power_meter_notify() is serialized by the new lock too which<br /> generally helps to ensure that the order of handling firmware<br /> notifications is the same as the order of sending netlink messages<br /> related to them.<br /> <br /> In addition, notice that hwmon_device_register_with_info() may fail<br /> in which case resource-&gt;hwmon_dev will become an error pointer,<br /> so add checks to avoid attempting to unregister the hwmon device<br /> pointer to by it in that case to acpi_power_meter_notify() and<br /> acpi_power_meter_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc-&gt;domains<br /> <br /> Fix out-of-range access of bc-&gt;domains in imx8m_blk_ctrl_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: r8152: fix resume reset deadlock<br /> <br /> rtl8152 can trigger device reset during reset which<br /> potentially can result in a deadlock:<br /> <br /> **** DPM device timeout after 10 seconds; 15 seconds until panic ****<br /> Call Trace:<br /> <br /> schedule+0x483/0x1370<br /> schedule_preempt_disabled+0x15/0x30<br /> __mutex_lock_common+0x1fd/0x470<br /> __rtl8152_set_mac_address+0x80/0x1f0<br /> dev_set_mac_address+0x7f/0x150<br /> rtl8152_post_reset+0x72/0x150<br /> usb_reset_device+0x1d0/0x220<br /> rtl8152_resume+0x99/0xc0<br /> usb_resume_interface+0x3e/0xc0<br /> usb_resume_both+0x104/0x150<br /> usb_resume+0x22/0x110<br /> <br /> The problem is that rtl8152 resume calls reset under<br /> tp-&gt;control mutex while reset basically re-enters rtl8152<br /> and attempts to acquire the same tp-&gt;control lock once<br /> again.<br /> <br /> Reset INACCESSIBLE device outside of tp-&gt;control mutex<br /> scope to avoid recursive mutex_lock() deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix NULL pointer dereference in ceph_mds_auth_match()<br /> <br /> The CephFS kernel client has regression starting from 6.18-rc1.<br /> We have issue in ceph_mds_auth_match() if fs_name == NULL:<br /> <br /> const char fs_name = mdsc-&gt;fsc-&gt;mount_options-&gt;mds_namespace;<br /> ...<br /> if (auth-&gt;match.fs_name &amp;&amp; strcmp(auth-&gt;match.fs_name, fs_name)) {<br /> / fsname mismatch, try next one */<br /> return 0;<br /> }<br /> <br /> Patrick Donnelly suggested that: In summary, we should definitely start<br /> decoding `fs_name` from the MDSMap and do strict authorizations checks<br /> against it. Note that the `-o mds_namespace=foo` should only be used for<br /> selecting the file system to mount and nothing else. It&amp;#39;s possible<br /> no mds_namespace is specified but the kernel will mount the only<br /> file system that exists which may have name "foo".<br /> <br /> This patch reworks ceph_mdsmap_decode() and namespace_equals() with<br /> the goal of supporting the suggested concept. Now struct ceph_mdsmap<br /> contains m_fs_name field that receives copy of extracted FS name<br /> by ceph_extract_encoded_string(). For the case of "old" CephFS file<br /> systems, it is used "cephfs" name.<br /> <br /> [ idryomov: replace redundant %*pE with %s in ceph_mdsmap_decode(),<br /> get rid of a series of strlen() calls in ceph_namespace_match(),<br /> drop changes to namespace_equals() body to avoid treating empty<br /> mds_namespace as equal, drop changes to ceph_mdsc_handle_fsmap()<br /> as namespace_equals() isn&amp;#39;t an equivalent substitution there ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: fix memory leak in acp3x pdm dma ops

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: aloop: Fix racy access at PCM trigger<br /> <br /> The PCM trigger callback of aloop driver tries to check the PCM state<br /> and stop the stream of the tied substream in the corresponding cable.<br /> Since both check and stop operations are performed outside the cable<br /> lock, this may result in UAF when a program attempts to trigger<br /> frequently while opening/closing the tied stream, as spotted by<br /> fuzzers.<br /> <br /> For addressing the UAF, this patch changes two things:<br /> - It covers the most of code in loopback_check_format() with<br /> cable-&gt;lock spinlock, and add the proper NULL checks. This avoids<br /> already some racy accesses.<br /> - In addition, now we try to check the state of the capture PCM stream<br /> that may be stopped in this function, which was the major pain point<br /> leading to UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: handle changing device dma map requirements<br /> <br /> The initial state of dma_needs_unmap may be false, but change to true<br /> while mapping the data iterator. Enabling swiotlb is one such case that<br /> can change the result. The nvme driver needs to save the mapped dma<br /> vectors to be unmapped later, so allocate as needed during iteration<br /> rather than assume it was always allocated at the beginning. This fixes<br /> a NULL dereference from accessing an uninitialized dma_vecs when the<br /> device dma unmapping requirements change mid-iteration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cpsw: Execute ndo_set_rx_mode callback in a work queue<br /> <br /> Commit 1767bb2d47b7 ("ipv6: mcast: Don&amp;#39;t hold RTNL for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.") removed the RTNL lock for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this<br /> change triggered the following call trace on my BeagleBone Black board:<br /> WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/481<br /> RTNL: assertion failed at net/8021q/vlan_core.c (236)<br /> Modules linked in:<br /> CPU: 0 UID: 997 PID: 481 Comm: rpcbind Not tainted 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT<br /> Hardware name: Generic AM33XX (Flattened Device Tree)<br /> Call trace:<br /> unwind_backtrace from show_stack+0x28/0x2c<br /> show_stack from dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl from __warn+0xb8/0x11c<br /> __warn from warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt from vlan_for_each+0x120/0x124<br /> vlan_for_each from cpsw_add_mc_addr+0x54/0x98<br /> cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88<br /> __dev_mc_add from igmp6_group_added+0x84/0xec<br /> igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt from __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt from ret_fast_syscall+0x0/0x54<br /> <br /> This trace occurs because vlan_for_each() is called within<br /> cpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.<br /> Since modifying vlan_for_each() to operate without the RTNL lock is not<br /> straightforward, and because ndo_set_rx_mode() is invoked both with and<br /> without the RTNL lock across different code paths, simply adding<br /> rtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.<br /> <br /> To resolve this issue, we opt to execute the actual processing within<br /> a work queue, following the approach used by the icssg-prueth driver.<br /> <br /> Please note: To reproduce this issue, I manually reverted the changes to<br /> am335x-bone-common.dtsi from commit c477358e66a3 ("ARM: dts: am335x-bone:<br /> switch to new cpsw switch drv") in order to revert to the legacy cpsw<br /> driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: toshiba_haps: Fix memory leaks in add/remove routines<br /> <br /> toshiba_haps_add() leaks the haps object allocated by it if it returns<br /> an error after allocating that object successfully.<br /> <br /> toshiba_haps_remove() does not free the object pointed to by<br /> toshiba_haps before clearing that pointer, so it becomes unreachable<br /> allocated memory.<br /> <br /> Address these memory leaks by using devm_kzalloc() for allocating<br /> the memory in question.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, shmem: prevent infinite loop on truncate race<br /> <br /> When truncating a large swap entry, shmem_free_swap() returns 0 when the<br /> entry&amp;#39;s index doesn&amp;#39;t match the given index due to lookup alignment. The<br /> failure fallback path checks if the entry crosses the end border and<br /> aborts when it happens, so truncate won&amp;#39;t erase an unexpected entry or<br /> range. But one scenario was ignored.<br /> <br /> When `index` points to the middle of a large swap entry, and the large<br /> swap entry doesn&amp;#39;t go across the end border, find_get_entries() will<br /> return that large swap entry as the first item in the batch with<br /> `indices[0]` equal to `index`. The entry&amp;#39;s base index will be smaller<br /> than `indices[0]`, so shmem_free_swap() will fail and return 0 due to the<br /> "base

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()<br /> <br /> `i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of data<br /> into `ihid-&gt;rawbuf`.<br /> <br /> The former can come from the userspace in the hidraw driver and is only<br /> bounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set<br /> `max_buffer_size` field of `struct hid_ll_driver` which we do not).<br /> <br /> The latter has size determined at runtime by the maximum size of<br /> different report types you could receive on any particular device and<br /> can be a much smaller value.<br /> <br /> Fix this by truncating `recv_len` to `ihid-&gt;bufsize - sizeof(__le16)`.<br /> <br /> The impact is low since access to hidraw devices requires root.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready()<br /> <br /> When the socket is closed while in TCP_LISTEN a callback is run to<br /> flush all outstanding packets, which in turns calls<br /> nvmet_tcp_listen_data_ready() with the sk_callback_lock held.<br /> So we need to check if we are in TCP_LISTEN before attempting<br /> to get the sk_callback_lock() to avoid a deadlock.