Vulnerabilities

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.

The Social Sharing Plugin – Sassy Social Share plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s &amp;#39;Sassy_Social_Share&amp;#39; shortcode in all versions up to, and including, 3.3.58 due to insufficient input sanitization and output escaping on user supplied attributes such as &amp;#39;url&amp;#39;. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Appointment Booking Calendar — Simply Schedule Appointments Booking Plugin plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.6.6.20. This is due to missing or incorrect nonce validation on the ssa_factory_reset() function. This makes it possible for unauthenticated attackers to reset the plugin&amp;#39;s settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

A stack-based buffer overflow in the built-in web server in Moxa NPort W2150A/W2250A Series firmware version 2.3 and prior allows a remote attacker to exploit the vulnerability by sending crafted payload to the web service. Successful exploitation of the vulnerability could result in denial of service.<br /> <br />

A cross-site scripting (XSS) vulnerability in Customer Support System v1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the firstname parameter at /customer_support/index.php?page=customer_list.

A cross-site scripting (XSS) vulnerability in Customer Support System v1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the email parameter at /customer_support/index.php?page=customer_list.

A cross-site scripting (XSS) vulnerability in Customer Support System v1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the contact parameter at /customer_support/index.php?page=customer_list.

A cross-site scripting (XSS) vulnerability in Customer Support System v1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the subject parameter at /customer_support/index.php?page=new_ticket.