Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix potential out-of-bounds access on the first resume<br /> <br /> Out-of-bounds access occurs if the fast device is expanded unexpectedly<br /> before the first-time resume of the cache table. This happens because<br /> expanding the fast device requires reloading the cache table for<br /> cache_create to allocate new in-core data structures that fit the new<br /> size, and the check in cache_preresume is not performed during the<br /> first resume, leading to the issue.<br /> <br /> Reproduce steps:<br /> <br /> 1. prepare component devices:<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc 262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> <br /> 2. load a cache table of 512 cache blocks, and deliberately expand the<br /> fast device before resuming the cache, making the in-core data<br /> structures inadequate.<br /> <br /> dmsetup create cache --notable<br /> dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"<br /> dmsetup resume cdata<br /> dmsetup resume cache<br /> <br /> 3. suspend the cache to write out the in-core dirty bitset and hint<br /> array, leading to out-of-bounds access to the dirty bitset at offset<br /> 0x40:<br /> <br /> dmsetup suspend cache<br /> <br /> KASAN reports:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80<br /> Read of size 8 at addr ffffc90000085040 by task dmsetup/90<br /> <br /> (...snip...)<br /> The buggy address belongs to the virtual mapping at<br /> [ffffc90000085000, ffffc90000087000) created by:<br /> cache_ctr+0x176a/0x35f0<br /> <br /> (...snip...)<br /> Memory state around the buggy address:<br /> ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> &gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> <br /> Fix by checking the size change on the first resume.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix out-of-bounds access to the dirty bitset when resizing<br /> <br /> dm-cache checks the dirty bits of the cache blocks to be dropped when<br /> shrinking the fast device, but an index bug in bitset iteration causes<br /> out-of-bounds access.<br /> <br /> Reproduce steps:<br /> <br /> 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc 262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds<br /> access to the dirty bitset (offset 0x80)<br /> <br /> dmsetup suspend cache<br /> dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup resume cdata<br /> dmsetup resume cache<br /> <br /> KASAN reports:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0<br /> Read of size 8 at addr ffffc900000f3080 by task dmsetup/131<br /> <br /> (...snip...)<br /> The buggy address belongs to the virtual mapping at<br /> [ffffc900000f3000, ffffc900000f5000) created by:<br /> cache_ctr+0x176a/0x35f0<br /> <br /> (...snip...)<br /> Memory state around the buggy address:<br /> ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> <br /> Fix by making the index post-incremented.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix flushing uninitialized delayed_work on cache_ctr error<br /> <br /> An unexpected WARN_ON from flush_work() may occur when cache creation<br /> fails, caused by destroying the uninitialized delayed_work waker in the<br /> error path of cache_create(). For example, the warning appears on the<br /> superblock checksum error.<br /> <br /> Reproduce steps:<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc 262144"<br /> dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> Kernel logs:<br /> <br /> (snip)<br /> WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890<br /> <br /> Fix by pulling out the cancel_delayed_work_sync() from the constructor&amp;#39;s<br /> error path. This patch doesn&amp;#39;t affect the use-after-free fix for<br /> concurrent dm_resume and dm_destroy (commit 6a459d8edbdb ("dm cache: Fix<br /> UAF in destroy()")) as cache_dtr is not changed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()<br /> <br /> Avoid a possible buffer overflow if size is larger than 4K.<br /> <br /> (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp<br /> <br /> ksmbd_user_session_put should be called under smb3_preauth_hash_rsp().<br /> It will avoid freeing session before calling smb3_preauth_hash_rsp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix the missing xa_store error check<br /> <br /> xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot<br /> be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed,<br /> so check error for xa_store() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create<br /> <br /> There is a race condition between ksmbd_smb2_session_create and<br /> ksmbd_expire_session. This patch add missing sessions_table_lock<br /> while adding/deleting session from global session table.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-tpg: prevent the risk of a division by zero<br /> <br /> As reported by Coverity, the logic at tpg_precalculate_line()<br /> blindly rescales the buffer even when scaled_witdh is equal to<br /> zero. If this ever happens, this will cause a division by zero.<br /> <br /> Instead, add a WARN_ON_ONCE() to trigger such cases and return<br /> without doing any precalculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: avoid overflow in damon_feed_loop_next_input()<br /> <br /> damon_feed_loop_next_input() is inefficient and fragile to overflows. <br /> Specifically, &amp;#39;score_goal_diff_bp&amp;#39; calculation can overflow when &amp;#39;score&amp;#39;<br /> is high. The calculation is actually unnecessary at all because &amp;#39;goal&amp;#39; is<br /> a constant of value 10,000. Calculation of &amp;#39;compensation&amp;#39; is again<br /> fragile to overflow. Final calculation of return value for under-achiving<br /> case is again fragile to overflow when the current score is<br /> under-achieving the target.<br /> <br /> Add two corner cases handling at the beginning of the function to make the<br /> body easier to read, and rewrite the body of the function to avoid<br /> overflows and the unnecessary bp value calcuation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: avoid vport access in idpf_get_link_ksettings<br /> <br /> When the device control plane is removed or the platform<br /> running device control plane is rebooted, a reset is detected<br /> on the driver. On driver reset, it releases the resources and<br /> waits for the reset to complete. If the reset fails, it takes<br /> the error path and releases the vport lock. At this time if the<br /> monitoring tools tries to access link settings, it call traces<br /> for accessing released vport pointer.<br /> <br /> To avoid it, move link_speed_mbps to netdev_priv structure<br /> which removes the dependency on vport pointer and the vport lock<br /> in idpf_get_link_ksettings. Also use netif_carrier_ok()<br /> to check the link status and adjust the offsetof to use link_up<br /> instead of link_speed_mbps.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/sve: Discard stale CPU state when handling SVE traps<br /> <br /> The logic for handling SVE traps manipulates saved FPSIMD/SVE state<br /> incorrectly, and a race with preemption can result in a task having<br /> TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state<br /> is stale (e.g. with SVE traps enabled). This has been observed to result<br /> in warnings from do_sve_acc() where SVE traps are not expected while<br /> TIF_SVE is set:<br /> <br /> | if (test_and_set_thread_flag(TIF_SVE))<br /> | WARN_ON(1); /* SVE access shouldn&amp;#39;t have trapped */<br /> <br /> Warnings of this form have been reported intermittently, e.g.<br /> <br /> https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/<br /> https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/<br /> <br /> The race can occur when the SVE trap handler is preempted before and<br /> after manipulating the saved FPSIMD/SVE state, starting and ending on<br /> the same CPU, e.g.<br /> <br /> | void do_sve_acc(unsigned long esr, struct pt_regs *regs)<br /> | {<br /> | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled<br /> | // task-&gt;fpsimd_cpu is 0.<br /> | // per_cpu_ptr(&amp;fpsimd_last_state, 0) is task.<br /> |<br /> | ...<br /> |<br /> | // Preempted; migrated from CPU 0 to CPU 1.<br /> | // TIF_FOREIGN_FPSTATE is set.<br /> |<br /> | get_cpu_fpsimd_context();<br /> |<br /> | if (test_and_set_thread_flag(TIF_SVE))<br /> | WARN_ON(1); /* SVE access shouldn&amp;#39;t have trapped */<br /> |<br /> | sve_init_regs() {<br /> | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {<br /> | ...<br /> | } else {<br /> | fpsimd_to_sve(current);<br /> | current-&gt;thread.fp_type = FP_STATE_SVE;<br /> | }<br /> | }<br /> |<br /> | put_cpu_fpsimd_context();<br /> |<br /> | // Preempted; migrated from CPU 1 to CPU 0.<br /> | // task-&gt;fpsimd_cpu is still 0<br /> | // If per_cpu_ptr(&amp;fpsimd_last_state, 0) is still task then:<br /> | // - Stale HW state is reused (with SVE traps enabled)<br /> | // - TIF_FOREIGN_FPSTATE is cleared<br /> | // - A return to userspace skips HW state restore<br /> | }<br /> <br /> Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set<br /> by calling fpsimd_flush_task_state() to detach from the saved CPU<br /> state. This ensures that a subsequent context switch will not reuse the<br /> stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the<br /> new state to be reloaded from memory prior to a return to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> signal: restore the override_rlimit logic<br /> <br /> Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of<br /> ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of<br /> signals. However now it&amp;#39;s enforced unconditionally, even if<br /> override_rlimit is set. This behavior change caused production issues. <br /> <br /> For example, if the limit is reached and a process receives a SIGSEGV<br /> signal, sigqueue_alloc fails to allocate the necessary resources for the<br /> signal delivery, preventing the signal from being delivered with siginfo. <br /> This prevents the process from correctly identifying the fault address and<br /> handling the error. From the user-space perspective, applications are<br /> unaware that the limit has been reached and that the siginfo is<br /> effectively &amp;#39;corrupted&amp;#39;. This can lead to unpredictable behavior and<br /> crashes, as we observed with java applications.<br /> <br /> Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip<br /> the comparison to max there if override_rlimit is set. This effectively<br /> restores the old behavior.