Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix deferred split queue races during migration<br /> <br /> migrate_folio_move() records the deferred split queue state from src and<br /> replays it on dst. Replaying it after remove_migration_ptes(src, dst, 0)<br /> makes dst visible before it is requeued, so a concurrent rmap-removal path<br /> can mark dst partially mapped and trip the WARN in deferred_split_folio().<br /> <br /> Move the requeue before remove_migration_ptes() so dst is back on the<br /> deferred split queue before it becomes visible again.<br /> <br /> Because migration still holds dst locked at that point, teach<br /> deferred_split_scan() to requeue a folio when folio_trylock() fails. <br /> Otherwise a fully mapped underused folio can be dequeued by the shrinker<br /> and silently lost from split_queue.<br /> <br /> [ziy@nvidia.com: move the comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: xlnx: Only access buffer information if IPI is buffered<br /> <br /> In the receive callback check if message is NULL to prevent<br /> possibility of crash by NULL pointer dereferencing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply()<br /> <br /> If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both<br /> protocol and result, this is currently not treated as an error. In case<br /> of ac-&gt;negotiating == true and ac-&gt;protocol &gt; 0, this leads to setting<br /> ac-&gt;protocol = 0 and ac-&gt;ops = NULL. Thereafter, the check for<br /> ac-&gt;protocol != protocol returns false, and init_protocol() is not<br /> called. Subsequently, ac-&gt;ops-&gt;handle_reply() is called, which leads to<br /> a null pointer dereference, because ac-&gt;ops is still NULL.<br /> <br /> This patch changes the check for ac-&gt;protocol != protocol to<br /> !ac-&gt;protocol, as this also includes the case when the protocol was set<br /> to zero in the message. This causes the message to be treated as<br /> containing a bad auth protocol.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm mirror: fix integer overflow in create_dirty_log()<br /> <br /> The argument count calculation in create_dirty_log() performs<br /> `*args_used = 2 + param_count` before validating against argc. When a<br /> user provides a param_count close to UINT_MAX via the device mapper<br /> table string, this unsigned addition wraps around to a small value,<br /> causing the subsequent `argc = 2 is already guaranteed, the subtraction is<br /> safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()<br /> <br /> ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read<br /> when the queue reader or writer index from hardware exceeds<br /> REMOTE_QUEUE_SIZE (60).<br /> <br /> A compromised service processor can trigger this by writing an<br /> out-of-range value to the reader or writer MMIO register before<br /> asserting an interrupt. Since writer is re-read from hardware on<br /> every loop iteration, it can also be set to an out-of-range value<br /> after the loop has already started.<br /> <br /> The root cause is that get_queue_reader() and get_queue_writer() return<br /> raw readl() values that are passed directly into get_queue_entry(),<br /> which computes:<br /> <br /> queue_begin + reader * sizeof(struct remote_input)<br /> <br /> with no bounds check. This unchecked MMIO address is then passed to<br /> memcpy_fromio(), reading 8 bytes from unintended device registers.<br /> For sufficiently large values the address falls outside the PCI BAR<br /> mapping entirely, triggering a machine check exception.<br /> <br /> Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of<br /> the loop body, before any call to get_queue_entry(). On an out-of-range<br /> value, reset the reader register to 0 via set_queue_reader() before<br /> breaking, so that normal queue operation can resume if the corrupted<br /> hardware state is transient.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: validate damos_quota_goal-&gt;nid for node_mem_{used,free}_bp<br /> <br /> Patch series "mm/damon/core: validate damos_quota_goal-&gt;nid".<br /> <br /> node_mem[cg]_{used,free}_bp DAMOS quota goals receive the node id. The<br /> node id is used for si_meminfo_node() and NODE_DATA() without proper<br /> validation. As a result, privileged users can trigger an out of bounds<br /> memory access using DAMON_SYSFS. Fix the issues.<br /> <br /> The issue was originally reported [1] with a fix by another author. The<br /> original author announced [2] that they will stop working including the<br /> fix that was still in the review stage. Hence I&amp;#39;m restarting this.<br /> <br /> <br /> This patch (of 2):<br /> <br /> Users can set damos_quota_goal-&gt;nid with arbitrary value for<br /> node_mem_{used,free}_bp. But DAMON core is using those for<br /> si_meminfo_node() without the validation of the value. This can result in<br /> out of bounds memory access. The issue can actually triggered using DAMON<br /> user-space tool (damo), like below.<br /> <br /> $ sudo ./damo start --damos_action stat \<br /> --damos_quota_goal node_mem_used_bp 50% -1 \<br /> --damos_quota_interval 1s<br /> $ sudo dmesg<br /> [...]<br /> [ 65.565986] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098<br /> <br /> Fix this issue by adding the validation of the given node. If an invalid<br /> node id is given, it returns 0% for used memory ratio, and 100% for free<br /> memory ratio.

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.