Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()<br /> <br /> When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns<br /> negative error value on error. So not NULL check is not sufficient<br /> to deteremine if IRQ is valid. Check that IRQ is greater then zero<br /> to ensure it is valid.<br /> <br /> There is no issue at probe time but at runtime user can invoke<br /> .set_channels which results in the following call chain.<br /> am65_cpsw_set_channels()<br /> am65_cpsw_nuss_update_tx_rx_chns()<br /> am65_cpsw_nuss_remove_tx_chns()<br /> am65_cpsw_nuss_init_tx_chns()<br /> <br /> At this point if am65_cpsw_nuss_init_tx_chns() fails due to<br /> k3_udma_glue_tx_get_irq() then tx_chn-&gt;irq will be set to a<br /> negative value.<br /> <br /> Then, at subsequent .set_channels with higher channel count we<br /> will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()<br /> leading to a kernel warning.<br /> <br /> The issue is present in the original commit that introduced this driver,<br /> although there, am65_cpsw_nuss_update_tx_rx_chns() existed as<br /> am65_cpsw_nuss_update_tx_chns().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix oops when unload drivers paralleling<br /> <br /> When unload hclge driver, it tries to disable sriov first for each<br /> ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at<br /> the time, because it removes all the ae_dev nodes, and it may cause<br /> oops.<br /> <br /> But we can&amp;#39;t simply use hnae3_common_lock for this. Because in the<br /> process flow of pci_disable_sriov(), it will trigger the remove flow<br /> of VF, which will also take hnae3_common_lock.<br /> <br /> To fixes it, introduce a new mutex to protect the unload process.

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.

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.

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.

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.