Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix dma_buffer leak on bus acquire failure<br /> <br /> wilc_wlan_firmware_download() allocates dma_buffer with kmalloc() at<br /> the top of the function and uses a &amp;#39;fail:&amp;#39; label to free it via<br /> kfree(dma_buffer) on error.<br /> <br /> All later error paths correctly use &amp;#39;goto fail&amp;#39; to route through this<br /> cleanup. However, the early failure path after the first acquire_bus()<br /> call uses a bare &amp;#39;return ret;&amp;#39;, which leaks dma_buffer whenever the bus<br /> acquire fails.<br /> <br /> Replace the early return with goto fail so the existing cleanup path<br /> runs.<br /> <br /> Found via a custom Coccinelle semantic patch hunting for kmalloc&amp;#39;d<br /> locals leaked on early-return error paths in driver firmware-download<br /> code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix metabuf leak in inode xattr initialization<br /> <br /> commit bb88e8da0025 ("erofs: use meta buffers for xattr operations")<br /> converted xattr operations to use on-stack erofs_buf instances.<br /> erofs_init_inode_xattrs() uses such a metabuf while reading the inline<br /> xattr header and shared xattr id array.<br /> <br /> Some error paths after erofs_read_metabuf() leave through out_unlock<br /> without dropping the metabuf, so the folio reference can leak.<br /> <br /> Consolidate the cleanup at out_unlock. erofs_put_metabuf() is a<br /> no-op if no folio has been acquired, and this keeps all paths after<br /> taking EROFS_I_BL_XATTR_BIT covered by a single cleanup site.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pds_core: fix debugfs_lookup dentry leak and error handling<br /> <br /> debugfs_lookup() returns a dentry with an elevated reference count that<br /> must be released with dput(). The current code discards the returned<br /> dentry without calling dput(), causing a reference leak on every<br /> firmware reset recovery.<br /> <br /> Additionally, when CONFIG_DEBUG_FS is disabled, debugfs_lookup()<br /> returns ERR_PTR(-ENODEV), not NULL. The current check passes for error<br /> pointers and would call dput() on an invalid pointer, causing a crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-mapping: move dma_map_resource() sanity check into debug code<br /> <br /> dma_map_resource() uses pfn_valid() to ensure the range is not RAM.<br /> However, pfn_valid() only checks for availability of the memory map for<br /> a PFN but it does not ensure that the PFN is actually backed by RAM. On<br /> ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that<br /> share a section with RAM will falsely trigger the WARN_ON_ONCE and cause<br /> dma_map_resource() to return DMA_MAPPING_ERROR.<br /> <br /> This causes a WARNING on Raspberry Pi 4 during spi_bcm2835 probe because<br /> the SPI FIFO register (0xfe204004) falls in the same sparsemem section<br /> as the end of RAM (0xf8000000-0xfbffffff), both in section 31<br /> (0xf8000000-0xffffffff).<br /> <br /> Move the sanity check from dma_map_resource() into debug_dma_map_phys()<br /> and replace the unreliable pfn_valid() with pfn_valid() &amp;&amp;<br /> !PageReserved(), which correctly identifies actual usable RAM without<br /> false positives for MMIO regions that happen to have struct pages.<br /> <br /> Since dma_map_resource() is dma_map_phys(DMA_ATTR_MMIO), the check<br /> applies equally to both APIs. Any non-reserved page represents kernel<br /> memory to a sufficient degree that using DMA_ATTR_MMIO on it is almost<br /> certainly wrong and risks breaking coherency on non-coherent platforms.<br /> ZONE_DEVICE pages used for PCI P2P DMA (MEMORY_DEVICE_PCI_P2PDMA) have<br /> PageReserved set, so they will not trigger a false positive.<br /> <br /> The check no longer blocks the mapping and uses err_printk() to<br /> integrate with dma-debug filtering.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: close durable scavenger races against m_fp_list lookups<br /> <br /> ksmbd_durable_scavenger() has two related races against any walker<br /> that iterates f_ci-&gt;m_fp_list, including ksmbd_lookup_fd_inode()<br /> (used by ksmbd_vfs_rename) and the share-mode checks in<br /> fs/smb/server/smb_common.c.<br /> <br /> (1) fp-&gt;node list-head reuse. Durable-preserved handles can remain<br /> linked on f_ci-&gt;m_fp_list after session teardown so share-mode checks<br /> still see them while the handle is reconnectable. The scavenger<br /> collected expired handles by adding fp-&gt;node to a local<br /> scavenger_list after removing them from the global durable idr.<br /> Because fp-&gt;node is the same list_head used by m_fp_list,<br /> list_add(&amp;fp-&gt;node, &amp;scavenger_list) overwrites the m_fp_list links<br /> and corrupts both lists. CONFIG_DEBUG_LIST can report this on the<br /> share-mode walk path.<br /> <br /> (2) Refcount race against m_fp_list walkers. The scavenger qualifies<br /> an expired durable handle with atomic_read(&amp;fp-&gt;refcount) &gt; 1 and<br /> fp-&gt;conn under global_ft.lock, removes fp from global_ft, then drops<br /> global_ft.lock before unlinking fp from m_fp_list and freeing it.<br /> During that gap fp is still linked on m_fp_list with f_state ==<br /> FP_INITED. ksmbd_lookup_fd_inode() under m_lock read calls<br /> ksmbd_fp_get() (atomic_inc_not_zero on refcount that is still 1) and<br /> takes a live reference; the scavenger then unlinks and frees fp<br /> while the holder owns a reference, leading to UAF on the holder&amp;#39;s<br /> subsequent ksmbd_fd_put() and on any field reads performed by a<br /> concurrent share-mode walker that iterates m_fp_list without taking<br /> ksmbd_fp_get() (smb_check_perm_dleases-like paths).<br /> <br /> Fix both:<br /> <br /> * Stop reusing fp-&gt;node as a scavenger-private list node. Remove<br /> one expired handle from global_ft under global_ft.lock, take an<br /> explicit transient reference, drop the lock, unlink fp-&gt;node<br /> from m_fp_list under f_ci-&gt;m_lock, then drop both the durable<br /> lifetime and transient references with atomic_sub_and_test(2,<br /> &amp;fp-&gt;refcount). If the scavenger is the last putter the close<br /> runs there; otherwise an in-flight holder that already raced<br /> through the m_fp_list lookup owns the final close via its<br /> ksmbd_fd_put() path. The one-at-a-time disposal can rescan the<br /> durable idr when multiple handles expire in the same pass, but<br /> durable scavenging is a background expiration path and the final<br /> full scan recomputes min_timeout before the next wait.<br /> <br /> * Clear fp-&gt;persistent_id inside __ksmbd_remove_durable_fd() right<br /> after idr_remove(), so a delayed final close from a holder that<br /> snatched fp does not re-issue idr_remove() on a persistent id<br /> that idr_alloc_cyclic() in ksmbd_open_durable_fd() may have<br /> already handed out to a brand-new durable handle.<br /> <br /> * Bypass the per-conn open_files_count decrement in<br /> __put_fd_final() when fp is detached from any session table<br /> (fp-&gt;conn cleared by session_fd_check() at durable preserve --<br /> paired with the volatile_id clear at unpublish, so checking<br /> fp-&gt;conn alone is sufficient). The walker that owns the final<br /> close runs from an unrelated work-&gt;conn whose<br /> stats.open_files_count never tracked this durable fp; without<br /> this guard the holder would underflow that unrelated counter.<br /> <br /> The two races are folded into one patch because patch (1) alone<br /> cleans up the corrupted list but leaves a deterministic UAF window<br /> for m_fp_list walkers that the transient-reference and<br /> persistent_id discipline in (2) close; bisecting onto an<br /> intermediate state would land on a UAF that pre-patch chaos merely<br /> made less reproducible.<br /> <br /> Validation:<br /> * CONFIG_DEBUG_LIST coverage for the list_head reuse path.<br /> * KASAN-enabled direct SMB2 durable-handle coverage that exercised<br /> ksmbd_durable_scavenger() and non-NULL ksmbd_lookup_fd_inode()<br /> returns while durable handles expired under concurrent rename<br /> lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING<br /> reports.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pds_core: fix error handling in pdsc_devcmd_wait<br /> <br /> Fix two cases where pdsc_devcmd_wait() returns stale success from<br /> the completion register instead of an error:<br /> <br /> 1. FW crash: If firmware stops running, the wait loop breaks early with<br /> running=false. The condition "if ((!done || timeout) &amp;&amp; running)" is<br /> false, so error handling is bypassed and stale status is returned.<br /> Check !running first and return -ENXIO.<br /> <br /> 2. Timeout: If a command times out, err is set to -ETIMEDOUT but then<br /> overwritten by pdsc_err_to_errno(status) which reads stale status.<br /> Return -ETIMEDOUT immediately after cleaning up.<br /> <br /> Both errors now propagate to pdsc_devcmd_locked() which queues<br /> health_work for recovery.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_inner: release local_lock before re-enabling softirqs<br /> <br /> Quoting sashiko:<br /> In the error path, local_bh_enable() is called before<br /> local_unlock_nested_bh().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX<br /> <br /> adm1266_nvmem_read_blackbox() declares a 5-byte stack buffer and<br /> passes it to i2c_smbus_read_block_data() to retrieve the 4-byte<br /> BLACKBOX_INFO response. i2c_smbus_read_block_data() does not honour<br /> caller buffer sizes -- it memcpy()s data.block[0] bytes from the<br /> SMBus transaction (where data.block[0] is the length byte returned by<br /> the slave device, up to I2C_SMBUS_BLOCK_MAX = 32):<br /> <br /> memcpy(values, &amp;data.block[1], data.block[0]);<br /> <br /> If the device returns any block length above 5, the call overflows<br /> the caller&amp;#39;s 5-byte stack buffer before the post-call<br /> <br /> if (ret != 4)<br /> return -EIO;<br /> <br /> check has a chance to reject the response.<br /> <br /> Widen the local buffer to I2C_SMBUS_BLOCK_MAX so the helper has room<br /> for any well-formed SMBus block response, matching the convention used<br /> by the other i2c_smbus_read_block_data() callers in this driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix SID memory leak in set_posix_acl_entries_dacl() on overflow<br /> <br /> Commit 299f962c0b02 ("ksmbd: use check_add_overflow() to prevent u16<br /> DACL size overflow") added check_add_overflow() guards that break out<br /> of the ACE-building loops in set_posix_acl_entries_dacl() when the<br /> accumulated DACL size would wrap past 65535.<br /> <br /> However, each iteration allocates a struct smb_sid via kmalloc_obj()<br /> at the top of the loop and relies on the kfree(sid) call at the end<br /> of the loop body (the &amp;#39;pass_same_sid&amp;#39; label in the first loop, and<br /> the explicit kfree at the tail of the second loop) to release it.<br /> The newly introduced &amp;#39;break&amp;#39; statements bypass those kfree() calls,<br /> leaking the sid buffer every time an overflow is detected.<br /> <br /> A malicious or malformed file with enough POSIX ACL entries to trip<br /> the overflow check will leak one or more struct smb_sid allocations<br /> on every request that touches the file&amp;#39;s DACL, providing a trivial<br /> kernel memory exhaustion vector.<br /> <br /> Free sid before breaking out of the loops to plug the leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ioam: refresh hdr pointer before ioam6_event()<br /> <br /> Reported by Sashiko:<br /> <br /> In ipv6_hop_ioam(), the hdr pointer is initialized to point into the<br /> skb&amp;#39;s linear data buffer. Later, the code calls skb_ensure_writable(),<br /> which might reallocate the buffer:<br /> <br /> if (skb_ensure_writable(skb, optoff + 2 + hdr-&gt;opt_len))<br /> goto drop;<br /> <br /> /* Trace pointer may have changed */<br /> trace = (struct ioam6_trace_hdr *)(skb_network_header(skb)<br /> + optoff + sizeof(*hdr));<br /> <br /> ioam6_fill_trace_data(skb, ns, trace, true);<br /> <br /> ioam6_event(IOAM6_EVENT_TRACE, dev_net(skb-&gt;dev),<br /> GFP_ATOMIC, (void *)trace, hdr-&gt;opt_len - 2);<br /> <br /> If the skb is cloned or lacks sufficient linear headroom,<br /> skb_ensure_writable() will invoke pskb_expand_head(), which reallocates<br /> the skb&amp;#39;s data buffer and frees the old one, invalidating pointers to<br /> it. While the code recalculates the trace pointer immediately after the<br /> call to skb_ensure_writable(), it fails to recalculate the hdr pointer.<br /> <br /> This patch fixes the above by recalculating the hdr pointer before<br /> passing hdr-&gt;opt_len to ioam6_event(), so that we avoid any UaF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: asihpi: Fix potential OOB array access at reading cache<br /> <br /> find_control() to retrieve a cached info accesses the array with the<br /> given index blindly, which may lead to an OOB array access.<br /> Add a sanity check for avoiding it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Don&amp;#39;t setup bogus iov_iter for silencing<br /> <br /> At transition to the iov_iter for PCM data transfer, we blindly<br /> applied the iov_iter setup also for silencing (i.e. data = NULL), and<br /> it leads to a calculation of bogus iov_iter. Fortunately this didn&amp;#39;t<br /> cause troubles on most of architectures but it goes wrong on RISC-V<br /> now, causing a NULL dereference.<br /> <br /> Handle the NULL data case to treat the silencing in interleaved_copy()<br /> for addressing the bug above. noninterleaved_copy() has already the<br /> NULL data handling, so it doesn&amp;#39;t need changes.