Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, fix definer&amp;#39;s HWS_SET32 macro for negative offset<br /> <br /> When bit offset for HWS_SET32 macro is negative,<br /> UBSAN complains about the shift-out-of-bounds:<br /> <br /> UBSAN: shift-out-of-bounds in<br /> drivers/net/ethernet/mellanox/mlx5/core/steering/hws/definer.c:177:2<br /> shift exponent -8 is negative

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ravb: Fix missing rtnl lock in suspend/resume path<br /> <br /> Fix the suspend/resume path by ensuring the rtnl lock is held where<br /> required. Calls to ravb_open, ravb_close and wol operations must be<br /> performed under the rtnl lock to prevent conflicts with ongoing ndo<br /> operations.<br /> <br /> Without this fix, the following warning is triggered:<br /> [ 39.032969] =============================<br /> [ 39.032983] WARNING: suspicious RCU usage<br /> [ 39.033019] -----------------------------<br /> [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious<br /> rcu_dereference_protected() usage!<br /> ...<br /> [ 39.033597] stack backtrace:<br /> [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted<br /> 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7<br /> [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on<br /> r9a08g045s33 (DT)<br /> [ 39.033628] Call trace:<br /> [ 39.033633] show_stack+0x14/0x1c (C)<br /> [ 39.033652] dump_stack_lvl+0xb4/0xc4<br /> [ 39.033664] dump_stack+0x14/0x1c<br /> [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c<br /> [ 39.033682] phy_detach+0x160/0x190<br /> [ 39.033694] phy_disconnect+0x40/0x54<br /> [ 39.033703] ravb_close+0x6c/0x1cc<br /> [ 39.033714] ravb_suspend+0x48/0x120<br /> [ 39.033721] dpm_run_callback+0x4c/0x14c<br /> [ 39.033731] device_suspend+0x11c/0x4dc<br /> [ 39.033740] dpm_suspend+0xdc/0x214<br /> [ 39.033748] dpm_suspend_start+0x48/0x60<br /> [ 39.033758] suspend_devices_and_enter+0x124/0x574<br /> [ 39.033769] pm_suspend+0x1ac/0x274<br /> [ 39.033778] state_store+0x88/0x124<br /> [ 39.033788] kobj_attr_store+0x14/0x24<br /> [ 39.033798] sysfs_kf_write+0x48/0x6c<br /> [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8<br /> [ 39.033817] vfs_write+0x27c/0x378<br /> [ 39.033825] ksys_write+0x64/0xf4<br /> [ 39.033833] __arm64_sys_write+0x18/0x20<br /> [ 39.033841] invoke_syscall+0x44/0x104<br /> [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4<br /> [ 39.033862] do_el0_svc+0x18/0x20<br /> [ 39.033870] el0_svc+0x3c/0xf0<br /> [ 39.033880] el0t_64_sync_handler+0xc0/0xc4<br /> [ 39.033888] el0t_64_sync+0x154/0x158<br /> [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Fix warnings during S3 suspend<br /> <br /> The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),<br /> and the later one may call the preempt_schedule_common() function,<br /> resulting in a thread switch and causing the CPU to be in an interrupt<br /> enabled state after the enable_gpe_wakeup() function returns, leading<br /> to the warnings as follow.<br /> <br /> [ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8<br /> [ C0] ...<br /> [ C0] Call Trace:<br /> [ C0] [] show_stack+0x64/0x188<br /> [ C0] [] dump_stack_lvl+0x60/0x88<br /> [ C0] [] __warn+0x8c/0x148<br /> [ C0] [] report_bug+0x1c0/0x2b0<br /> [ C0] [] do_bp+0x204/0x3b8<br /> [ C0] [] exception_handlers+0x1924/0x10000<br /> [ C0] [] ktime_get+0xbc/0xc8<br /> [ C0] [] tick_sched_timer+0x30/0xb0<br /> [ C0] [] __hrtimer_run_queues+0x160/0x378<br /> [ C0] [] hrtimer_interrupt+0x144/0x388<br /> [ C0] [] constant_timer_interrupt+0x38/0x48<br /> [ C0] [] __handle_irq_event_percpu+0x64/0x1e8<br /> [ C0] [] handle_irq_event_percpu+0x20/0x80<br /> [ C0] [] handle_percpu_irq+0x5c/0x98<br /> [ C0] [] generic_handle_domain_irq+0x30/0x48<br /> [ C0] [] handle_cpu_irq+0x70/0xa8<br /> [ C0] [] handle_loongarch_irq+0x30/0x48<br /> [ C0] [] do_vint+0x80/0xe0<br /> [ C0] [] finish_task_switch.isra.0+0x8c/0x2a8<br /> [ C0] [] __schedule+0x314/0xa48<br /> [ C0] [] schedule+0x58/0xf0<br /> [ C0] [] worker_thread+0x224/0x498<br /> [ C0] [] kthread+0xf8/0x108<br /> [ C0] [] ret_from_kernel_thread+0xc/0xa4<br /> [ C0]<br /> [ C0] ---[ end trace 0000000000000000 ]---<br /> <br /> The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect<br /> acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause<br /> a thread switch. Since there is no longer concurrent execution during<br /> loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()<br /> directly in enable_gpe_wakeup().<br /> <br /> The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid<br /> breaking S3 wakeup due to might_sleep()").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: th1520: Fix a NULL vs IS_ERR() bug<br /> <br /> The devm_ioremap() function doesn&amp;#39;t return error pointers, it returns<br /> NULL. Update the error checking to match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rhashtable: Fix potential deadlock by moving schedule_work outside lock<br /> <br /> Move the hash table growth check and work scheduling outside the<br /> rht lock to prevent a possible circular locking dependency.<br /> <br /> The original implementation could trigger a lockdep warning due to<br /> a potential deadlock scenario involving nested locks between<br /> rhashtable bucket, rq lock, and dsq lock. By relocating the<br /> growth check and work scheduling after releasing the rth lock, we break<br /> this potential deadlock chain.<br /> <br /> This change expands the flexibility of rhashtable by removing<br /> restrictive locking that previously limited its use in scheduler<br /> and workqueue contexts.<br /> <br /> Import to say that this calls rht_grow_above_75(), which reads from<br /> struct rhashtable without holding the lock, if this is a problem, we can<br /> move the check to the lock, and schedule the workqueue after the lock.<br /> <br /> <br /> Modified so that atomic_inc is also moved outside of the bucket<br /> lock along with the growth above 75% check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: test: Fix potential null dereference in firewire kunit test<br /> <br /> kunit_kzalloc() may return a NULL pointer, dereferencing it without<br /> NULL check may lead to NULL dereference.<br /> Add a NULL check for test_state.

AVE System Web Client v2.1.131.13992 was discovered to contain a cross-site scripting (XSS) vulnerability.

An issue was discovered on Tuoshi/Dionlink LT15D 4G Wi-Fi devices through M7628NNxlSPv2xUI_v1.0.1802.10.08_P4 and LT21B devices through M7628xUSAxUIv2_v1.0.1481.15.02_P0. A unauthenticated remote attacker with network access can exploit a command injection vulnerability. The /goform/formJsonAjaxReq endpoint fails to sanitize shell metacharacters sent via JSON parameters, thus allowing attackers to execute arbitrary OS commands with root privileges.

Nagios XI 2024R1.2.2 is vulnerable to an open redirect flaw on the Tools page, exploitable by users with read-only permissions. This vulnerability allows an attacker to craft a malicious link that redirects users to an arbitrary external URL without their consent.

FooGallery – Responsive Photo Gallery, Image Viewer, Justified, Masonry and Carousel 2.4.29 was found to be vulnerable. The web application dynamically generates web content without validating the source of the potentially untrusted data in myapp/extensions/albums/admin/class-meta boxes.php.

WP Activity Log 5.3.2 was found to be vulnerable. Unvalidated user input is used directly in an unserialize function in myapp/classes/Writers/class-csv-writer.php.

Mastodon is a self-hosted, federated microblogging platform. In versions prior to 4.1.23, 4.2.16, and 4.3.4, when the visibility for domain blocks/reasons is set to "users" (localized English string: "To logged-in users"), users that are not yet approved can view the block reasons. Instance admins that do not want their domain blocks to be public are impacted. Versions 4.1.23, 4.2.16, and 4.3.4 fix the issue.