Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()<br /> <br /> Update struct hid_descriptor to better reflect the mandatory and<br /> optional parts of the HID Descriptor as per USB HID 1.11 specification.<br /> Note: the kernel currently does not parse any optional HID class<br /> descriptors, only the mandatory report descriptor.<br /> <br /> Update all references to member element desc[0] to rpt_desc.<br /> <br /> Add test to verify bLength and bNumDescriptors values are valid.<br /> <br /> Replace the for loop with direct access to the mandatory HID class<br /> descriptor member for the report descriptor. This eliminates the<br /> possibility of getting an out-of-bounds fault.<br /> <br /> Add a warning message if the HID descriptor contains any unsupported<br /> optional HID class descriptors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Kill timer properly at removal<br /> <br /> The USB-audio MIDI code initializes the timer, but in a rare case, the<br /> driver might be freed without the disconnect call. This leaves the<br /> timer in an active state while the assigned object is released via<br /> snd_usbmidi_free(), which ends up with a kernel warning when the debug<br /> configuration is enabled, as spotted by fuzzer.<br /> <br /> For avoiding the problem, put timer_shutdown_sync() at<br /> snd_usbmidi_free(), so that the timer can be killed properly.<br /> While we&amp;#39;re at it, replace the existing timer_delete_sync() at the<br /> disconnect callback with timer_shutdown_sync(), too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> espintcp: remove encap socket caching to avoid reference leak<br /> <br /> The current scheme for caching the encap socket can lead to reference<br /> leaks when we try to delete the netns.<br /> <br /> The reference chain is: xfrm_state -&gt; enacp_sk -&gt; netns<br /> <br /> Since the encap socket is a userspace socket, it holds a reference on<br /> the netns. If we delete the espintcp state (through flush or<br /> individual delete) before removing the netns, the reference on the<br /> socket is dropped and the netns is correctly deleted. Otherwise, the<br /> netns may not be reachable anymore (if all processes within the ns<br /> have terminated), so we cannot delete the xfrm state to drop its<br /> reference on the socket.<br /> <br /> This patch results in a small (~2% in my tests) performance<br /> regression.<br /> <br /> A GC-type mechanism could be added for the socket cache, to clear<br /> references if the state hasn&amp;#39;t been used "recently", but it&amp;#39;s a lot<br /> more complex than just not caching the socket.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Don&amp;#39;t treat wb connector as physical in create_validate_stream_for_sink<br /> <br /> Don&amp;#39;t try to operate on a drm_wb_connector as an amdgpu_dm_connector.<br /> While dereferencing aconnector-&gt;base will "work" it&amp;#39;s wrong and<br /> might lead to unknown bad things. Just... don&amp;#39;t.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set()<br /> <br /> Enlarge the critical section in ring_buffer_subbuf_order_set() to<br /> ensure that error handling takes place with per-buffer mutex held,<br /> thus preventing list corruption and other concurrency-related issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify<br /> <br /> During our test, it is found that a warning can be trigger in try_grab_folio<br /> as follow:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)<br /> RIP: 0010:try_grab_folio+0x106/0x130<br /> Call Trace:<br /> <br /> follow_huge_pmd+0x240/0x8e0<br /> follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0<br /> follow_pud_mask.constprop.0.isra.0+0x14a/0x170<br /> follow_page_mask+0x1c2/0x1f0<br /> __get_user_pages+0x176/0x950<br /> __gup_longterm_locked+0x15b/0x1060<br /> ? gup_fast+0x120/0x1f0<br /> gup_fast_fallback+0x17e/0x230<br /> get_user_pages_fast+0x5f/0x80<br /> vmci_host_unlocked_ioctl+0x21c/0xf80<br /> RIP: 0033:0x54d2cd<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Digging into the source, context-&gt;notify_page may init by get_user_pages_fast<br /> and can be seen in vmci_ctx_unset_notify which will try to put_page. However<br /> get_user_pages_fast is not finished here and lead to following<br /> try_grab_folio warning. The race condition is shown as follow:<br /> <br /> cpu0 cpu1<br /> vmci_host_do_set_notify<br /> vmci_host_setup_notify<br /> get_user_pages_fast(uva, 1, FOLL_WRITE, &amp;context-&gt;notify_page);<br /> lockless_pages_from_mm<br /> gup_pgd_range<br /> gup_huge_pmd // update &amp;context-&gt;notify_page<br /> vmci_host_do_set_notify<br /> vmci_ctx_unset_notify<br /> notify_page = context-&gt;notify_page;<br /> if (notify_page)<br /> put_page(notify_page); // page is freed<br /> __gup_longterm_locked<br /> __get_user_pages<br /> follow_trans_huge_pmd<br /> try_grab_folio // warn here<br /> <br /> To slove this, use local variable page to make notify_page can be seen<br /> after finish get_user_pages_fast.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: don&amp;#39;t warn when if there is a FW error<br /> <br /> iwl_trans_reclaim is warning if it is called when the FW is not alive.<br /> But if it is called when there is a pending restart, i.e. after a FW<br /> error, there is no need to warn, instead - return silently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf: insert memory barrier before updating num_fences<br /> <br /> smp_store_mb() inserts memory barrier after storing operation.<br /> It is different with what the comment is originally aiming so Null<br /> pointer dereference can be happened if memory update is reordered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cadence: macb: Fix a possible deadlock in macb_halt_tx.<br /> <br /> There is a situation where after THALT is set high, TGO stays high as<br /> well. Because jiffies are never updated, as we are in a context with<br /> interrupts disabled, we never exit that loop and have a deadlock.<br /> <br /> That deadlock was noticed on a sama5d4 device that stayed locked for days.<br /> <br /> Use retries instead of jiffies so that the timeout really works and we do<br /> not have a deadlock anymore.

The PeepSo Core: Groups plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Group Description field in all versions up to, and including, 6.4.6.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Element Pack Addons for Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘data-caption’ attribute in all versions up to, and including, 8.0.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Zulip is an open-source team chat application. From versions 2.0.0-rc1 to before 10.4 in Zulip Server, the /digest/ URL of a server shows a preview of what the email weekly digest would contain. This URL, though not the digest itself, contains a cross-site scripting (XSS) vulnerability in both topic names and channel names. This issue has been fixed in Zulip Server 10.4. A workaround for this issue involves denying access to /digest/.