Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: handle attr_set_size() errors when truncating files<br /> <br /> If attr_set_size() fails while truncating down, the error is silently<br /> ignored and the inode may be left in an inconsistent state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix user_ref race between scrub and refill paths<br /> <br /> The io_zcrx_put_niov_uref() function uses a non-atomic<br /> check-then-decrement pattern (atomic_read followed by separate<br /> atomic_dec) to manipulate user_refs. This is serialized against other<br /> callers by rq_lock, but io_zcrx_scrub() modifies the same counter with<br /> atomic_xchg() WITHOUT holding rq_lock.<br /> <br /> On SMP systems, the following race exists:<br /> <br /> CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock)<br /> put_niov_uref:<br /> atomic_read(uref) - 1<br /> // window opens<br /> atomic_xchg(uref, 0) - 1<br /> return_niov_freelist(niov) [PUSH #1]<br /> // window closes<br /> atomic_dec(uref) - wraps to -1<br /> returns true<br /> return_niov(niov)<br /> return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE]<br /> <br /> The same niov is pushed to the freelist twice, causing free_count to<br /> exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds<br /> write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent<br /> slab object.<br /> <br /> Fix this by replacing the non-atomic read-then-dec in<br /> io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically<br /> tests and decrements user_refs. This makes the operation safe against<br /> concurrent atomic_xchg from scrub without requiring scrub to acquire<br /> rq_lock.<br /> <br /> [pavel: removed a warning and a comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/buffer: add alert in try_to_free_buffers() for folios without buffers<br /> <br /> try_to_free_buffers() can be called on folios with no buffers attached<br /> when filemap_release_folio() is invoked on a folio belonging to a mapping<br /> with AS_RELEASE_ALWAYS set but no release_folio operation defined.<br /> <br /> In such cases, folio_needs_release() returns true because of the<br /> AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This<br /> causes try_to_free_buffers() to call drop_buffers() on a folio with no<br /> buffers, leading to a null pointer dereference.<br /> <br /> Adding a check in try_to_free_buffers() to return early if the folio has no<br /> buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration.<br /> This provides defensive hardening.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix NULL pointer issue buffer funcs<br /> <br /> If SDMA block not enabled, buffer_funcs will not initialize,<br /> fix the null pointer issue if buffer_funcs not initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: mtk-smi: fix device leaks on common probe<br /> <br /> Make sure to drop the reference taken when looking up the SMI device<br /> during common probe on late probe failure (e.g. probe deferral) and on<br /> driver unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: mtk-smi: fix device leak on larb probe<br /> <br /> Make sure to drop the reference taken when looking up the SMI device<br /> during larb probe on late probe failure (e.g. probe deferral) and on<br /> driver unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls<br /> <br /> The size of the data behind of scontrol-&gt;ipc_control_data for bytes<br /> controls is:<br /> [1] sizeof(struct sof_ipc4_control_data) + // kernel only struct<br /> [2] sizeof(struct sof_abi_hdr)) + payload<br /> <br /> The max_size specifies the size of [2] and it is coming from topology.<br /> <br /> Change the function to take this into account and allocate adequate amount<br /> of memory behind scontrol-&gt;ipc_control_data.<br /> <br /> With the change we will allocate [1] amount more memory to be able to hold<br /> the full size of data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels<br /> <br /> MHI stack offers the &amp;#39;auto_queue&amp;#39; feature, which allows the MHI stack to<br /> auto queue the buffers for the RX path (DL channel). Though this feature<br /> simplifies the client driver design, it introduces race between the client<br /> drivers and the MHI stack. For instance, with auto_queue, the &amp;#39;dl_callback&amp;#39;<br /> for the DL channel may get called before the client driver is fully probed.<br /> This means, by the time the dl_callback gets called, the client driver&amp;#39;s<br /> structures might not be initialized, leading to NULL ptr dereference.<br /> <br /> Currently, the drivers have to workaround this issue by initializing the<br /> internal structures before calling mhi_prepare_for_transfer_autoqueue().<br /> But even so, there is a chance that the client driver&amp;#39;s internal code path<br /> may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is<br /> called, leading to similar NULL ptr dereference. This issue has been<br /> reported on the Qcom X1E80100 CRD machines affecting boot.<br /> <br /> So to properly fix all these races, drop the MHI &amp;#39;auto_queue&amp;#39; feature<br /> altogether and let the client driver (QRTR) manage the RX buffers manually.<br /> In the QRTR driver, queue the RX buffers based on the ring length during<br /> probe and recycle the buffers in &amp;#39;dl_callback&amp;#39; once they are consumed. This<br /> also warrants removing the setting of &amp;#39;auto_queue&amp;#39; flag from controller<br /> drivers.<br /> <br /> Currently, this &amp;#39;auto_queue&amp;#39; feature is only enabled for IPCR DL channel.<br /> So only the QRTR client driver requires the modification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: core: fix race in driver_override_show() and use core helper<br /> <br /> The driver_override_show function reads the driver_override string<br /> without holding the device_lock. However, the store function modifies<br /> and frees the string while holding the device_lock. This creates a race<br /> condition where the string can be freed by the store function while<br /> being read by the show function, leading to a use-after-free.<br /> <br /> To fix this, replace the rpmsg_string_attr macro with explicit show and<br /> store functions. The new driver_override_store uses the standard<br /> driver_set_override helper. Since the introduction of<br /> driver_set_override, the comments in include/linux/rpmsg.h have stated<br /> that this helper must be used to set or clear driver_override, but the<br /> implementation was not updated until now.<br /> <br /> Because driver_set_override modifies and frees the string while holding<br /> the device_lock, the new driver_override_show now correctly holds the<br /> device_lock during the read operation to prevent the race.<br /> <br /> Additionally, since rpmsg_string_attr has only ever been used for<br /> driver_override, removing the macro simplifies the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: ensure sb-&gt;s_fs_info is always cleaned up<br /> <br /> When hfsplus was converted to the new mount api a bug was introduced by<br /> changing the allocation pattern of sb-&gt;s_fs_info. If setup_bdev_super()<br /> fails after a new superblock has been allocated by sget_fc(), but before<br /> hfsplus_fill_super() takes ownership of the filesystem-specific s_fs_info<br /> data it was leaked.<br /> <br /> Fix this by freeing sb-&gt;s_fs_info in hfsplus_kill_super().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()<br /> <br /> Simplify the code by using device managed memory allocations.<br /> <br /> This also fixes a memory leak in rtw_register_hw(). The supported bands<br /> were not freed in the error path.<br /> <br /> Copied from commit 145df52a8671 ("wifi: rtw89: Convert<br /> rtw89_core_set_supported_band to use devm_*").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: core: fix resource leak in most_register_interface error paths<br /> <br /> The function most_register_interface() did not correctly release resources<br /> if it failed early (before registering the device). In these cases, it<br /> returned an error code immediately, leaking the memory allocated for the<br /> interface.<br /> <br /> Fix this by initializing the device early via device_initialize() and<br /> calling put_device() on all error paths.<br /> <br /> The most_register_interface() is expected to call put_device() on<br /> error which frees the resources allocated in the caller. The<br /> put_device() either calls release_mdev() or dim2_release(),<br /> depending on the caller.<br /> <br /> Switch to using device_add() instead of device_register() to handle<br /> the split initialization.