Vulnerabilities

rplay through 3.3.2 allows attackers to cause a denial of service (SIGSEGV and daemon crash) or possibly have unspecified other impact. This occurs in memcpy in the RPLAY_DATA case in rplay_unpack in librplay/rplay.c, potentially reachable via packet data with no authentication.

Apache Geode is vulnerable to CSRF attacks through GET requests to the Management and Monitoring REST API that could allow an attacker who has tricked a user into giving up their Geode session credentials to submit malicious commands on the target system on behalf of the authenticated user.<br /> <br /> <br /> This issue affects Apache Geode: versions 1.10 through 1.15.1<br /> <br /> Users are recommended to upgrade to version 1.15.2, which fixes the issue.

The Related Posts Lite plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 1.12 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

The Theme Editor plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 3.0. This is due to missing or incorrect nonce validation on the &amp;#39;theme_editor_theme&amp;#39; page. This makes it possible for unauthenticated attackers to achieve remote code execution via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mvsas: Fix use-after-free bugs in mvs_work_queue<br /> <br /> During the detaching of Marvell&amp;#39;s SAS/SATA controller, the original code<br /> calls cancel_delayed_work() in mvs_free() to cancel the delayed work<br /> item mwq-&gt;work_q. However, if mwq-&gt;work_q is already running, the<br /> cancel_delayed_work() may fail to cancel it. This can lead to<br /> use-after-free scenarios where mvs_free() frees the mvs_info while<br /> mvs_work_queue() is still executing and attempts to access the<br /> already-freed mvs_info.<br /> <br /> A typical race condition is illustrated below:<br /> <br /> CPU 0 (remove) | CPU 1 (delayed work callback)<br /> mvs_pci_remove() |<br /> mvs_free() | mvs_work_queue()<br /> cancel_delayed_work() |<br /> kfree(mvi) |<br /> | mvi-&gt; // UAF<br /> <br /> Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure<br /> that the delayed work item is properly canceled and any executing<br /> delayed work item completes before the mvs_info is deallocated.<br /> <br /> This bug was found by static analysis.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Fix use-after-free in tb_dp_dprx_work<br /> <br /> The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(),<br /> which does not ensure that the delayed work item tunnel-&gt;dprx_work has<br /> fully completed if it was already running. This leads to use-after-free<br /> scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while<br /> tunnel-&gt;dprx_work remains active and attempts to dereference tb_tunnel<br /> in tb_dp_dprx_work().<br /> <br /> A typical race condition is illustrated below:<br /> <br /> CPU 0 | CPU 1<br /> tb_dp_tunnel_active() |<br /> tb_deactivate_and_free_tunnel()| tb_dp_dprx_start()<br /> tb_tunnel_deactivate() | queue_delayed_work()<br /> tb_dp_activate() |<br /> tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker<br /> cancel_delayed_work() |<br /> tb_tunnel_put(tunnel); |<br /> | tunnel = container_of(...); //UAF<br /> | tunnel-&gt; //UAF<br /> <br /> Replacing cancel_delayed_work() with cancel_delayed_work_sync() is<br /> not feasible as it would introduce a deadlock: both tb_dp_dprx_work()<br /> and the cleanup path acquire tb-&gt;lock, and cancel_delayed_work_sync()<br /> would wait indefinitely for the work item that cannot proceed.<br /> <br /> Instead, implement proper reference counting:<br /> - If cancel_delayed_work() returns true (work is pending), we release<br /> the reference in the stop function.<br /> - If it returns false (work is executing or already completed), the<br /> reference is released in delayed work function itself.<br /> <br /> This ensures the tb_tunnel remains valid during work item execution<br /> while preventing memory leaks.<br /> <br /> This bug was found by static analysis.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mscc: ocelot: Fix use-after-free caused by cyclic delayed work<br /> <br /> The origin code calls cancel_delayed_work() in ocelot_stats_deinit()<br /> to cancel the cyclic delayed work item ocelot-&gt;stats_work. However,<br /> cancel_delayed_work() may fail to cancel the work item if it is already<br /> executing. While destroy_workqueue() does wait for all pending work items<br /> in the work queue to complete before destroying the work queue, it cannot<br /> prevent the delayed work item from being rescheduled within the<br /> ocelot_check_stats_work() function. This limitation exists because the<br /> delayed work item is only enqueued into the work queue after its timer<br /> expires. Before the timer expiration, destroy_workqueue() has no visibility<br /> of this pending work item. Once the work queue appears empty,<br /> destroy_workqueue() proceeds with destruction. When the timer eventually<br /> expires, the delayed work item gets queued again, leading to the following<br /> warning:<br /> <br /> workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-stats<br /> WARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0<br /> ...<br /> RIP: 0010:__queue_work+0x875/0xaf0<br /> ...<br /> RSP: 0018:ffff88806d108b10 EFLAGS: 00010086<br /> RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027<br /> RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88<br /> RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2<br /> R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000<br /> R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0<br /> FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> ? kasan_report+0xc6/0xf0<br /> ? __pfx_delayed_work_timer_fn+0x10/0x10<br /> ? __pfx_delayed_work_timer_fn+0x10/0x10<br /> call_timer_fn+0x25/0x1c0<br /> __run_timer_base.part.0+0x3be/0x8c0<br /> ? __pfx_delayed_work_timer_fn+0x10/0x10<br /> ? rcu_sched_clock_irq+0xb06/0x27d0<br /> ? __pfx___run_timer_base.part.0+0x10/0x10<br /> ? try_to_wake_up+0xb15/0x1960<br /> ? _raw_spin_lock_irq+0x80/0xe0<br /> ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> tmigr_handle_remote_up+0x603/0x7e0<br /> ? __pfx_tmigr_handle_remote_up+0x10/0x10<br /> ? sched_balance_trigger+0x1c0/0x9f0<br /> ? sched_tick+0x221/0x5a0<br /> ? _raw_spin_lock_irq+0x80/0xe0<br /> ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> ? tick_nohz_handler+0x339/0x440<br /> ? __pfx_tmigr_handle_remote_up+0x10/0x10<br /> __walk_groups.isra.0+0x42/0x150<br /> tmigr_handle_remote+0x1f4/0x2e0<br /> ? __pfx_tmigr_handle_remote+0x10/0x10<br /> ? ktime_get+0x60/0x140<br /> ? lapic_next_event+0x11/0x20<br /> ? clockevents_program_event+0x1d4/0x2a0<br /> ? hrtimer_interrupt+0x322/0x780<br /> handle_softirqs+0x16a/0x550<br /> irq_exit_rcu+0xaf/0xe0<br /> sysvec_apic_timer_interrupt+0x70/0x80<br /> <br /> ...<br /> <br /> The following diagram reveals the cause of the above warning:<br /> <br /> CPU 0 (remove) | CPU 1 (delayed work callback)<br /> mscc_ocelot_remove() |<br /> ocelot_deinit() | ocelot_check_stats_work()<br /> ocelot_stats_deinit() |<br /> cancel_delayed_work()| ...<br /> | queue_delayed_work()<br /> destroy_workqueue() | (wait a time)<br /> | __queue_work() //UAF<br /> <br /> The above scenario actually constitutes a UAF vulnerability.<br /> <br /> The ocelot_stats_deinit() is only invoked when initialization<br /> failure or resource destruction, so we must ensure that any<br /> delayed work items cannot be rescheduled.<br /> <br /> Replace cancel_delayed_work() with disable_delayed_work_sync()<br /> to guarantee proper cancellation of the delayed work item and<br /> ensure completion of any currently executing work before the<br /> workqueue is deallocated.<br /> <br /> A deadlock concern was considered: ocelot_stats_deinit() is called<br /> in a process context and is not holding any locks that the delayed<br /> work item might also need. Therefore, the use of the _sync() variant<br /> is safe here.<br /> <br /> This bug was identified through static analysis. To reproduce the<br /> issue and validate the fix, I simulated ocelot-swit<br /> ---truncated---

A vulnerability has been found in Nixdorf Wincor PORT IO Driver up to 1.0.0.1. This affects the function sub_11100 in the library wnport.sys of the component IOCTL Handler. Such manipulation leads to stack-based buffer overflow. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. Upgrading to version 3.0.0.1 is able to mitigate this issue. Upgrading the affected component is recommended. The vendor was contacted beforehand and was able to provide a patch very early.

The Kognetiks Chatbot plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on several functions in all versions up to, and including, 2.3.5. This makes it possible for unauthenticated attackers to upload limited safe files and erase conversations.

The PowerBI Embed Reports plugin for WordPress is vulnerable to Sensitive Information Disclosure in all versions up to, and including, 1.2.0. This is due to missing capability checks and authentication verification on the &amp;#39;testUser&amp;#39; endpoint accessible via the mo_epbr_admin_observer() function hooked on &amp;#39;init&amp;#39;. This makes it possible for unauthenticated attackers to access sensitive Azure AD user information including personal identifiable information (PII) such as displayName, mail, phones, department, or detailed OAuth error data including Azure AD Application/Client IDs, error codes, trace IDs, and correlation IDs.

The WPC Smart Quick View for WooCommerce plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 4.2.5 via the &amp;#39;woosq_quickview&amp;#39; AJAX endpoint due to insufficient restrictions on which posts can be included. This makes it possible for unauthenticated attackers to extract data from password protected, private, or draft products that they should not have access to.

The Redirection for Contact Form 7 plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s qs_date shortcode in all versions up to, and including, 3.2.6 due to insufficient input sanitization and output escaping on user supplied attributes. 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.