Vulnerabilities

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 /> dpaa2-switch: add bounds check for if_id in IRQ handler<br /> <br /> The IRQ handler extracts if_id from the upper 16 bits of the hardware<br /> status register and uses it to index into ethsw-&gt;ports[] without<br /> validation. Since if_id can be any 16-bit value (0-65535) but the ports<br /> array is only allocated with sw_attr.num_ifs elements, this can lead to<br /> an out-of-bounds read potentially.<br /> <br /> Add a bounds check before accessing the array, consistent with the<br /> existing validation in dpaa2_switch_rx().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: sync read disk super and set block size<br /> <br /> When the user performs a btrfs mount, the block device is not set<br /> correctly. The user sets the block size of the block device to 0x4000<br /> by executing the BLKBSZSET command.<br /> Since the block size change also changes the mapping-&gt;flags value, this<br /> further affects the result of the mapping_min_folio_order() calculation.<br /> <br /> Let&amp;#39;s analyze the following two scenarios:<br /> <br /> Scenario 1: Without executing the BLKBSZSET command, the block size is<br /> 0x1000, and mapping_min_folio_order() returns 0;<br /> <br /> Scenario 2: After executing the BLKBSZSET command, the block size is<br /> 0x4000, and mapping_min_folio_order() returns 2.<br /> <br /> do_read_cache_folio() allocates a folio before the BLKBSZSET command<br /> is executed. This results in the allocated folio having an order value<br /> of 0. Later, after BLKBSZSET is executed, the block size increases to<br /> 0x4000, and the mapping_min_folio_order() calculation result becomes 2.<br /> <br /> This leads to two undesirable consequences:<br /> <br /> 1. filemap_add_folio() triggers a VM_BUG_ON_FOLIO(folio_order(folio)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: tegra: Fix a memory leak in tegra_slink_probe()<br /> <br /> In tegra_slink_probe(), when platform_get_irq() fails, it directly<br /> returns from the function with an error code, which causes a memory leak.<br /> <br /> Replace it with a goto label to ensure proper cleanup.