Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> filemap: Fix bounds checking in filemap_read()<br /> <br /> If the caller supplies an iocb-&gt;ki_pos value that is close to the<br /> filesystem upper limit, and an iterator with a count that causes us to<br /> overflow that limit, then filemap_read() enters an infinite loop.<br /> <br /> This behaviour was discovered when testing xfstests generic/525 with the<br /> "localio" optimisation for loopback NFS mounts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reinitialize delayed ref list after deleting it from the list<br /> <br /> At insert_delayed_ref() if we need to update the action of an existing<br /> ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head&amp;#39;s<br /> ref_add_list using list_del(), which leaves the ref&amp;#39;s add_list member<br /> not reinitialized, as list_del() sets the next and prev members of the<br /> list to LIST_POISON1 and LIST_POISON2, respectively.<br /> <br /> If later we end up calling drop_delayed_ref() against the ref, which can<br /> happen during merging or when destroying delayed refs due to a transaction<br /> abort, we can trigger a crash since at drop_delayed_ref() we call<br /> list_empty() against the ref&amp;#39;s add_list, which returns false since<br /> the list was not reinitialized after the list_del() and as a consequence<br /> we call list_del() again at drop_delayed_ref(). This results in an<br /> invalid list access since the next and prev members are set to poison<br /> pointers, resulting in a splat if CONFIG_LIST_HARDENED and<br /> CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences<br /> otherwise.<br /> <br /> So fix this by deleting from the list with list_del_init() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: vertexcom: mse102x: Fix possible double free of TX skb<br /> <br /> The scope of the TX skb is wider than just mse102x_tx_frame_spi(),<br /> so in case the TX skb room needs to be expanded, we should free the<br /> the temporary skb instead of the original skb. Otherwise the original<br /> TX skb pointer would be freed again in mse102x_tx_work(), which leads<br /> to crashes:<br /> <br /> Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP<br /> CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23<br /> Hardware name: chargebyte Charge SOM DC-ONE (DT)<br /> Workqueue: events mse102x_tx_work [mse102x]<br /> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : skb_release_data+0xb8/0x1d8<br /> lr : skb_release_data+0x1ac/0x1d8<br /> sp : ffff8000819a3cc0<br /> x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0<br /> x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff<br /> x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50<br /> x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc<br /> x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000<br /> x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000<br /> x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8<br /> x8 : fffffc00001bc008<br /> x7 : 0000000000000000 x6 : 0000000000000008<br /> x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009<br /> x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> skb_release_data+0xb8/0x1d8<br /> kfree_skb_reason+0x48/0xb0<br /> mse102x_tx_work+0x164/0x35c [mse102x]<br /> process_one_work+0x138/0x260<br /> worker_thread+0x32c/0x438<br /> kthread+0x118/0x11c<br /> ret_from_fork+0x10/0x20<br /> Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs<br /> <br /> A recent change in the venus driver results in a stuck clock on the<br /> Lenovo ThinkPad X13s, for example, when streaming video in firefox:<br /> <br /> video_cc_mvs0_clk status stuck at &amp;#39;off&amp;#39;<br /> WARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c<br /> ...<br /> Call trace:<br /> clk_branch_wait+0x144/0x15c<br /> clk_branch2_enable+0x30/0x40<br /> clk_core_enable+0xd8/0x29c<br /> clk_enable+0x2c/0x4c<br /> vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core]<br /> coreid_power_v4+0x464/0x628 [venus_core]<br /> vdec_start_streaming+0xc4/0x510 [venus_dec]<br /> vb2_start_streaming+0x6c/0x180 [videobuf2_common]<br /> vb2_core_streamon+0x120/0x1dc [videobuf2_common]<br /> vb2_streamon+0x1c/0x6c [videobuf2_v4l2]<br /> v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem]<br /> v4l_streamon+0x24/0x30 [videodev]<br /> <br /> using the out-of-tree sm8350/sc8280xp venus support. [1]<br /> <br /> Update also the sm8350/sc8280xp GDSC definitions so that the hw control<br /> mode can be changed at runtime as the venus driver now requires.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: Initialization of the dangling pointer occurring in vsk-&gt;trans<br /> <br /> During loopback communication, a dangling pointer can be created in<br /> vsk-&gt;trans, potentially leading to a Use-After-Free condition. This<br /> issue is resolved by initializing vsk-&gt;trans to NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()<br /> <br /> Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():<br /> <br /> [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12<br /> [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry<br /> [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004<br /> [...]<br /> [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0<br /> [...]<br /> [ 57.331328] Call Trace:<br /> [ 57.331477] <br /> [...]<br /> [ 57.333511] ? do_user_addr_fault+0x3e5/0x740<br /> [ 57.333778] ? exc_page_fault+0x70/0x170<br /> [ 57.334016] ? asm_exc_page_fault+0x2b/0x30<br /> [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10<br /> [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0<br /> [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0<br /> [ 57.335164] ocfs2_xa_set+0x704/0xcf0<br /> [ 57.335381] ? _raw_spin_unlock+0x1a/0x40<br /> [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20<br /> [ 57.335915] ? trace_preempt_on+0x1e/0x70<br /> [ 57.336153] ? start_this_handle+0x16c/0x500<br /> [ 57.336410] ? preempt_count_sub+0x50/0x80<br /> [ 57.336656] ? _raw_read_unlock+0x20/0x40<br /> [ 57.336906] ? start_this_handle+0x16c/0x500<br /> [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0<br /> [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0<br /> [ 57.337706] ? ocfs2_start_trans+0x13d/0x290<br /> [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0<br /> [ 57.338207] ? dput+0x46/0x1c0<br /> [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30<br /> [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30<br /> [ 57.338948] __vfs_removexattr+0x92/0xc0<br /> [ 57.339182] __vfs_removexattr_locked+0xd5/0x190<br /> [ 57.339456] ? preempt_count_sub+0x50/0x80<br /> [ 57.339705] vfs_removexattr+0x5f/0x100<br /> [...]<br /> <br /> Reproducer uses faultinject facility to fail ocfs2_xa_remove() -&gt;<br /> ocfs2_xa_value_truncate() with -ENOMEM.<br /> <br /> In this case the comment mentions that we can return 0 if<br /> ocfs2_xa_cleanup_value_truncate() is going to wipe the entry<br /> anyway. But the following &amp;#39;rc&amp;#39; check is wrong and execution flow do<br /> &amp;#39;ocfs2_xa_remove_entry(loc);&amp;#39; twice:<br /> * 1st: in ocfs2_xa_cleanup_value_truncate();<br /> * 2nd: returning back to ocfs2_xa_remove() instead of going to &amp;#39;out&amp;#39;.<br /> <br /> Fix this by skipping the 2nd removal of the same entry and making<br /> syzkaller repro happy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: io_edgeport: fix use after free in debug printk<br /> <br /> The "dev_dbg(&amp;urb-&gt;dev-&gt;dev, ..." which happens after usb_free_urb(urb)<br /> is a use after free of the "urb" pointer. Store the "dev" pointer at the<br /> start of the function to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()<br /> <br /> The "*cmd" variable can be controlled by the user via debugfs. That means<br /> "new_cam" can be as high as 255 while the size of the uc-&gt;updated[] array<br /> is UCSI_MAX_ALTMODES (30).<br /> <br /> The call tree is:<br /> ucsi_cmd() // val comes from simple_attr_write_xsigned()<br /> -&gt; ucsi_send_command()<br /> -&gt; ucsi_send_command_common()<br /> -&gt; ucsi_run_command() // calls ucsi-&gt;ops-&gt;sync_control()<br /> -&gt; ucsi_ccg_sync_control()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: musb: sunxi: Fix accessing an released usb phy<br /> <br /> Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on<br /> exit") will cause that usb phy @glue-&gt;xceiv is accessed after released.<br /> <br /> 1) register platform driver @sunxi_musb_driver<br /> // get the usb phy @glue-&gt;xceiv<br /> sunxi_musb_probe() -&gt; devm_usb_get_phy().<br /> <br /> 2) register and unregister platform driver @musb_driver<br /> musb_probe() -&gt; sunxi_musb_init()<br /> use the phy here<br /> //the phy is released here<br /> musb_remove() -&gt; sunxi_musb_exit() -&gt; devm_usb_put_phy()<br /> <br /> 3) register @musb_driver again<br /> musb_probe() -&gt; sunxi_musb_init()<br /> use the phy here but the phy has been released at 2).<br /> ...<br /> <br /> Fixed by reverting the commit, namely, removing devm_usb_put_phy()<br /> from sunxi_musb_exit().