Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rkisp1: Fix IRQ disable race issue<br /> <br /> In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the<br /> interrupts and then apparently assumes that the interrupt handler won&amp;#39;t<br /> be running, and proceeds in the stop procedure. This is not the case, as<br /> the interrupt handler can already be running, which would lead to the<br /> ISP being disabled while the interrupt handler handling a captured<br /> frame.<br /> <br /> This brings up two issues: 1) the ISP could be powered off while the<br /> interrupt handler is still running and accessing registers, leading to<br /> board lockup, and 2) the interrupt handler code and the code that<br /> disables the streaming might do things that conflict.<br /> <br /> It is not clear to me if 2) causes a real issue, but 1) can be seen with<br /> a suitable delay (or printk in my case) in the interrupt handler,<br /> leading to board lockup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: Avoid touching renamed directory if parent does not change<br /> <br /> The VFS will not be locking moved directory if its parent does not<br /> change. Change ocfs2 rename code to avoid touching renamed directory if<br /> its parent does not change as without locking that can corrupt the<br /> filesystem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> reiserfs: Avoid touching renamed directory if parent does not change<br /> <br /> The VFS will not be locking moved directory if its parent does not<br /> change. Change reiserfs rename code to avoid touching renamed directory<br /> if its parent does not change as without locking that can corrupt the<br /> filesystem.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()<br /> <br /> Since &amp;#39;ieee80211_beacon_get()&amp;#39; can return NULL, &amp;#39;wfx_set_mfp_ap()&amp;#39;<br /> should check the return value before examining skb data. So convert<br /> the latter to return an appropriate error code and propagate it to<br /> return from &amp;#39;wfx_start_ap()&amp;#39; as well. Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spmi: mediatek: Fix UAF on device remove<br /> <br /> The pmif driver data that contains the clocks is allocated along with<br /> spmi_controller.<br /> On device remove, spmi_controller will be freed first, and then devres<br /> , including the clocks, will be cleanup.<br /> This leads to UAF because putting the clocks will access the clocks in<br /> the pmif driver data, which is already freed along with spmi_controller.<br /> <br /> This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and<br /> building the kernel with KASAN.<br /> <br /> Fix the UAF issue by using unmanaged clk_bulk_get() and putting the<br /> clocks before freeing spmi_controller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper()<br /> <br /> Return invalid error code -EINVAL for invalid block id.<br /> <br /> Fixes the below:<br /> <br /> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed &amp;#39;info&amp;#39; could be null (see line 1176)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Add mutex lock in control vblank irq<br /> <br /> Add a mutex lock to control vblank irq to synchronize vblank<br /> enable/disable operations happening from different threads to prevent<br /> race conditions while registering/unregistering the vblank irq callback.<br /> <br /> v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a<br /> parameter of dpu_encoder_phys.<br /> -Switch from atomic refcnt to a simple int counter as mutex has<br /> now been added<br /> v3: Mistakenly did not change wording in last version. It is done now.<br /> v2: Slightly changed wording of commit message<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/571854/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/ipoib: Fix mcast list locking<br /> <br /> Releasing the `priv-&gt;lock` while iterating the `priv-&gt;multicast_list` in<br /> `ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to<br /> remove the items while in the middle of iteration. If the mcast is removed<br /> while the lock was dropped, the for loop spins forever resulting in a hard<br /> lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):<br /> <br /> Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)<br /> -----------------------------------+-----------------------------------<br /> ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)<br /> spin_lock_irq(&amp;priv-&gt;lock) | __ipoib_ib_dev_flush(priv, ...)<br /> list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv-&gt;dev)<br /> &amp;priv-&gt;multicast_list, list) |<br /> ipoib_mcast_join(dev, mcast) |<br /> spin_unlock_irq(&amp;priv-&gt;lock) |<br /> | spin_lock_irqsave(&amp;priv-&gt;lock, flags)<br /> | list_for_each_entry_safe(mcast, tmcast,<br /> | &amp;priv-&gt;multicast_list, list)<br /> | list_del(&amp;mcast-&gt;list);<br /> | list_add_tail(&amp;mcast-&gt;list, &amp;remove_list)<br /> | spin_unlock_irqrestore(&amp;priv-&gt;lock, flags)<br /> spin_lock_irq(&amp;priv-&gt;lock) |<br /> | ipoib_mcast_remove_list(&amp;remove_list)<br /> (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,<br /> `priv-&gt;multicast_list` and we keep | remove_list, list)<br /> spinning on the `remove_list` of | &gt;&gt;&gt; wait_for_completion(&amp;mcast-&gt;done)<br /> the other thread which is blocked |<br /> and the list is still valid on |<br /> it&amp;#39;s stack.)<br /> <br /> Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent<br /> eventual sleeps.<br /> Unfortunately we could not reproduce the lockup and confirm this fix but<br /> based on the code review I think this fix should address such lockups.<br /> <br /> crash&gt; bc 31<br /> PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"<br /> --<br /> [exception RIP: ipoib_mcast_join_task+0x1b1]<br /> RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002<br /> RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000<br /> work (&amp;priv-&gt;mcast_task{,.work})<br /> RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000<br /> &amp;mcast-&gt;list<br /> RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000<br /> R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00<br /> mcast<br /> R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8<br /> dev priv (&amp;priv-&gt;lock) &amp;priv-&gt;multicast_list (aka head)<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> --- ---<br /> #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]<br /> #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967<br /> <br /> crash&gt; rx ff646f199a8c7e68<br /> ff646f199a8c7e68: ff1c6a1a04dc82f8 ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000<br /> mcast_task.work.func = 0xffffffffc0944910 ,<br /> mcast_mutex.owner.counter = 0xff1c69998efec000<br /> <br /> crash&gt; b 8<br /> PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"<br /> --<br /> #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646<br /> #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]<br /> #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]<br /> #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]<br /> #7 [ff<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to tag gcing flag on page during block migration<br /> <br /> It needs to add missing gcing flag on page during block migration,<br /> in order to garantee migrated data be persisted during checkpoint,<br /> otherwise out-of-order persistency between data and node may cause<br /> data corruption after SPOR.<br /> <br /> Similar issue was fixed by commit 2d1fe8a86bf5 ("f2fs: fix to tag<br /> gcing flag on page during file defragment").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix deadlock or deadcode of misusing dget()<br /> <br /> The lock order is incorrect between denty and its parent, we should<br /> always make sure that the parent get the lock first.<br /> <br /> But since this deadcode is never used and the parent dir will always<br /> be set from the callers, let&amp;#39;s just remove it.

The Total theme for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the total_order_sections() function in all versions up to, and including, 2.1.59. This makes it possible for authenticated attackers, with subscriber-level access and above, to repeat sections on the homepage.