Vulnerabilities

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix possible UAF in amdgpu_cs_pass1()<br /> <br /> Since the gang_size check is outside of chunk parsing<br /> loop, we need to reset i before we free the chunk data.<br /> <br /> Suggested by Ye Zhang (@VAR10CK) of Baidu Security.

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Sohelwpexpert WP Responsive Video my-wp-responsive-video allows DOM-Based XSS.This issue affects WP Responsive Video: from n/a through

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Maximilian Ruthe Mage Front End Forms mage-forms allows Stored XSS.This issue affects Mage Front End Forms: from n/a through

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in MartyThornley Photographer Connections photographer-connections allows Stored XSS.This issue affects Photographer Connections: from n/a through