Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: core: Fix thermal zone governor cleanup issues<br /> <br /> If thermal_zone_device_register_with_trips() fails after adding<br /> a thermal governor to the thermal zone being registered, the<br /> governor is not removed from it as appropriate which may lead to<br /> a memory leak.<br /> <br /> In turn, thermal_zone_device_unregister() calls thermal_set_governor()<br /> without acquiring the thermal zone lock beforehand which may race with<br /> a governor update via sysfs and may lead to a use-after-free in that<br /> case.<br /> <br /> Address these issues by adding two thermal_set_governor() calls, one to<br /> thermal_release() to remove the governor from the given thermal zone,<br /> and one to the thermal zone registration error path to cover failures<br /> preceding the thermal zone device registration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: call sk_data_ready() after listener migration<br /> <br /> When inet_csk_listen_stop() migrates an established child socket from<br /> a closing listener to another socket in the same SO_REUSEPORT group,<br /> the target listener gets a new accept-queue entry via<br /> inet_csk_reqsk_queue_add(), but that path never notifies the target<br /> listener&amp;#39;s waiters. A nonblocking accept() still works because it<br /> checks the queue directly, but poll()/epoll_wait() waiters and<br /> blocking accept() callers can also remain asleep indefinitely.<br /> <br /> Call READ_ONCE(nsk-&gt;sk_data_ready)(nsk) after a successful migration<br /> in inet_csk_listen_stop().<br /> <br /> However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired<br /> in reuseport_migrate_sock() is effectively transferred to<br /> nreq-&gt;rsk_listener. Another CPU can then dequeue nreq via accept()<br /> or listener shutdown, hit reqsk_put(), and drop that listener ref.<br /> Since listeners are SOCK_RCU_FREE, wrap the post-queue_add()<br /> dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also<br /> covers the existing sock_net(nsk) access in that path.<br /> <br /> The reqsk_timer_handler() path does not need the same changes for two<br /> reasons: half-open requests become readable only after the final ACK,<br /> where tcp_child_process() already wakes the listener; and once nreq is<br /> visible via inet_ehash_insert(), the success path no longer touches<br /> nsk directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Add missing save/restore handling of LBR MSRs<br /> <br /> MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by<br /> KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So<br /> save/restore is completely broken.<br /> <br /> Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to<br /> LBR MSRs from userspace only (as they are read-only MSRs) if LBR<br /> virtualization is enabled. Additionally, to correctly restore L1&amp;#39;s LBRs<br /> while L2 is running, make sure the LBRs are copied from the captured<br /> VMCB01 save area in svm_copy_vmrun_state().<br /> <br /> Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn&amp;#39;t<br /> reported as an MSR to save/restore.<br /> <br /> Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already<br /> handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM:<br /> Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the<br /> unsupported userspace write into a nop).<br /> <br /> [sean: guard with lbrv checks, massage changelog]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memfd_luo: fix physical address conversion in put_folios cleanup<br /> <br /> In memfd_luo_retrieve_folios()&amp;#39;s put_folios cleanup path:<br /> <br /> 1. kho_restore_folio() expects a phys_addr_t (physical address) but<br /> receives a raw PFN (pfolio-&gt;pfn). This causes kho_restore_page() to<br /> check the wrong physical address (pfn pfn check, matching the pattern used elsewhere in this file.<br /> <br /> This issue was identified by the AI review.<br /> https://sashiko.dev/#/patchset/20260323110747.193569-1-duanchenghao@kylinos.cn

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix memory leaks in rxkad_verify_response()<br /> <br /> Fix rxkad_verify_response() to free the ticket and the server key under all<br /> circumstances by initialising the ticket pointer to NULL and then making<br /> all paths through the function after the first allocation has been done go<br /> through a single common epilogue that just releases everything - where all<br /> the releases skip on a NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mtk-jpeg: fix use-after-free in release path due to uncancelled work<br /> <br /> The mtk_jpeg_release() function frees the context structure (ctx) without<br /> first cancelling any pending or running work in ctx-&gt;jpeg_work. This<br /> creates a race window where the workqueue callback may still be accessing<br /> the context memory after it has been freed.<br /> <br /> Race condition:<br /> <br /> CPU 0 (release) CPU 1 (workqueue)<br /> ---------------- ------------------<br /> close()<br /> mtk_jpeg_release()<br /> mtk_jpegenc_worker()<br /> ctx = work-&gt;data<br /> // accessing ctx<br /> <br /> kfree(ctx) // freed!<br /> access ctx // UAF!<br /> <br /> The work is queued via queue_work() during JPEG encode/decode operations<br /> (via mtk_jpeg_device_run). If the device is closed while work is pending<br /> or running, the work handler will access freed memory.<br /> <br /> Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This<br /> ordering is critical: if cancel_work_sync() is called after mutex_lock(),<br /> and the work handler also tries to acquire the same mutex, it would cause<br /> a deadlock.<br /> <br /> Note: The open error path does NOT need cancel_work_sync() because<br /> INIT_WORK() only initializes the work structure - it does not schedule<br /> it. Work is only scheduled later during ioctl operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix error handling in rxgk_extract_token()<br /> <br /> Fix a missing bit of error handling in rxgk_extract_token(): in the event<br /> that rxgk_decrypt_skb() returns -ENOMEM, it should just return that rather<br /> than continuing on (for anything else, it generates an abort).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown<br /> <br /> epf_ntb_epc_destroy() duplicates the teardown that the caller is<br /> supposed to do later. This leads to an oops when .allow_link fails or<br /> when .drop_link is performed. Remove the helper.<br /> <br /> Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC<br /> group lifetime, and pci_epc_put() in the .drop_link path is sufficient.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: fix damos_walk() vs kdamond_fn() exit race<br /> <br /> When kdamond_fn() main loop is finished, the function cancels remaining<br /> damos_walk() request and unset the damon_ctx-&gt;kdamond so that API callers<br /> and API functions themselves can show the context is terminated. <br /> damos_walk() adds the caller&amp;#39;s request to the queue first. After that, it<br /> shows if the kdamond of the damon_ctx is still running (damon_ctx-&gt;kdamond<br /> is set). Only if the kdamond is running, damos_walk() starts waiting for<br /> the kdamond&amp;#39;s handling of the newly added request.<br /> <br /> The damos_walk() requests registration and damon_ctx-&gt;kdamond unset are<br /> protected by different mutexes, though. Hence, damos_walk() could race<br /> with damon_ctx-&gt;kdamond unset, and result in deadlocks.<br /> <br /> For example, let&amp;#39;s suppose kdamond successfully finished the damow_walk()<br /> request cancelling. Right after that, damos_walk() is called for the<br /> context. It registers the new request, and shows the context is still<br /> running, because damon_ctx-&gt;kdamond unset is not yet done. Hence the<br /> damos_walk() caller starts waiting for the handling of the request. <br /> However, the kdamond is already on the termination steps, so it never<br /> handles the new request. As a result, the damos_walk() caller thread<br /> infinitely waits.<br /> <br /> Fix this by introducing another damon_ctx field, namely<br /> walk_control_obsolete. It is protected by the<br /> damon_ctx-&gt;walk_control_lock, which protects damos_walk() request<br /> registration. Initialize (unset) it in kdamond_fn() before letting<br /> damon_start() returns and set it just before the cancelling of the<br /> remaining damos_walk() request is executed. damos_walk() reads the<br /> obsolete field under the lock and avoids adding a new request.<br /> <br /> After this change, only requests that are guaranteed to be handled or<br /> cancelled are registered. Hence the after-registration DAMON context<br /> termination check is no longer needed. Remove it together.<br /> <br /> The issue is found by sashiko [1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (powerz) Avoid cacheline sharing for DMA buffer<br /> <br /> Depending on the architecture the transfer buffer may share a cacheline<br /> with the following mutex. As the buffer may be used for DMA, that is<br /> problematic.<br /> <br /> Use the high-level DMA helpers to make sure that cacheline sharing can<br /> not happen.<br /> <br /> Also drop the comment, as the helpers are documentation enough.<br /> <br /> https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: caiaq: Handle probe errors properly<br /> <br /> The probe procedure of setup_card() in caiaq driver doesn&amp;#39;t treat the<br /> error cases gracefully, e.g. the error from snd_card_register() calls<br /> snd_card_free() but continues. This would lead to a UAF for the<br /> further calls like snd_usb_caiaq_control_init(), as Berk suggested in<br /> another patch in the link below.<br /> <br /> However, the problem is not only that; in general, this function drops<br /> the all error handlings (as it&amp;#39;s a void function) although its caller<br /> can propagate an error to snd_probe(), which eventually calls<br /> snd_card_free() as a proper error path. That said, we should treat<br /> each error case in setup_card(), and just return the error code<br /> promptly, which is then handled later as a fatal error in snd_probe().<br /> <br /> This patch achieves it by changing the setup_card() to return an error<br /> code. Also, the superfluous snd_card_free() call is removed, too.<br /> <br /> Note that card-&gt;private_free can be set still safely at returning an<br /> error. All called functions in card_free() have checks of the<br /> unassigned resources or NULL checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: ns: Limit the total number of nodes<br /> <br /> Currently, the nameserver doesn&amp;#39;t limit the number of nodes it handles.<br /> This can be an attack vector if a malicious client starts registering<br /> random nodes, leading to memory exhaustion.<br /> <br /> Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is<br /> chosen based on the current platform requirements. If requirement changes<br /> in the future, this limit can be increased.