Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking<br /> <br /> The current implementation uses bias_pad_enable as a reference count to<br /> manage the shared bias pad for all UTMI PHYs. However, during system<br /> suspension with connected USB devices, multiple power-down requests for<br /> the UTMI pad result in a mismatch in the reference count, which in turn<br /> produces warnings such as:<br /> <br /> [ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170<br /> [ 237.763103] Call trace:<br /> [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170<br /> [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30<br /> [ 237.763110] phy_power_off+0x48/0x100<br /> [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500<br /> [ 237.763119] tegra_xusb_suspend+0x48/0x140<br /> [ 237.763122] platform_pm_suspend+0x2c/0xb0<br /> [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0<br /> [ 237.763127] __device_suspend+0x118/0x330<br /> [ 237.763129] dpm_suspend+0x10c/0x1f0<br /> [ 237.763130] dpm_suspend_start+0x88/0xb0<br /> [ 237.763132] suspend_devices_and_enter+0x120/0x500<br /> [ 237.763135] pm_suspend+0x1ec/0x270<br /> <br /> The root cause was traced back to the dynamic power-down changes<br /> introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"),<br /> where the UTMI pad was being powered down without verifying its current<br /> state. This unbalanced behavior led to discrepancies in the reference<br /> count.<br /> <br /> To rectify this issue, this patch replaces the single reference counter<br /> with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask<br /> corresponds to one of the four USB2 PHYs, allowing us to track each pad&amp;#39;s<br /> enablement status individually.<br /> <br /> With this change:<br /> - The bias pad is powered on only when the mask is clear.<br /> - Each UTMI pad is powered on or down based on its corresponding bit<br /> in the mask, preventing redundant operations.<br /> - The overall power state of the shared bias pad is maintained<br /> correctly during suspend/resume cycles.<br /> <br /> The mutex used to prevent race conditions during UTMI pad enable/disable<br /> operations has been moved from the tegra186_utmi_bias_pad_power_on/off<br /> functions to the parent functions tegra186_utmi_pad_power_on/down. This<br /> change ensures that there are no race conditions when updating the bitmask.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: fix race condition in unaccepted memory handling<br /> <br /> The page allocator tracks the number of zones that have unaccepted memory<br /> using static_branch_enc/dec() and uses that static branch in hot paths to<br /> determine if it needs to deal with unaccepted memory.<br /> <br /> Borislav and Thomas pointed out that the tracking is racy: operations on<br /> static_branch are not serialized against adding/removing unaccepted pages<br /> to/from the zone.<br /> <br /> Sanity checks inside static_branch machinery detects it:<br /> <br /> WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0<br /> <br /> The comment around the WARN() explains the problem:<br /> <br /> /*<br /> * Warn about the &amp;#39;-1&amp;#39; case though; since that means a<br /> * decrement is concurrent with a first (0-&gt;1) increment. IOW<br /> * people are trying to disable something that wasn&amp;#39;t yet fully<br /> * enabled. This suggests an ordering problem on the user side.<br /> */<br /> <br /> The effect of this static_branch optimization is only visible on<br /> microbenchmark.<br /> <br /> Instead of adding more complexity around it, remove it altogether.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: disable napi on driver removal<br /> <br /> A warning on driver removal started occurring after commit 9dd05df8403b<br /> ("net: warn if NAPI instance wasn&amp;#39;t shut down"). Disable tx napi before<br /> deleting it in mt76_dma_cleanup().<br /> <br /> WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100<br /> CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy)<br /> Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024<br /> RIP: 0010:__netif_napi_del_locked+0xf0/0x100<br /> Call Trace:<br /> <br /> mt76_dma_cleanup+0x54/0x2f0 [mt76]<br /> mt7921_pci_remove+0xd5/0x190 [mt7921e]<br /> pci_device_remove+0x47/0xc0<br /> device_release_driver_internal+0x19e/0x200<br /> driver_detach+0x48/0x90<br /> bus_remove_driver+0x6d/0xf0<br /> pci_unregister_driver+0x2e/0xb0<br /> __do_sys_delete_module.isra.0+0x197/0x2e0<br /> do_syscall_64+0x7b/0x160<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Tested with mt7921e but the same pattern can be actually applied to other<br /> mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled<br /> in their *_dma_init() functions and only toggled off and on again inside<br /> their suspend/resume/reset paths. So it should be okay to disable tx<br /> napi in such a generic way.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: csa unmap use uninterruptible lock<br /> <br /> After process exit to unmap csa and free GPU vm, if signal is accepted<br /> and then waiting to take vm lock is interrupted and return, it causes<br /> memory leaking and below warning backtrace.<br /> <br /> Change to use uninterruptible wait lock fix the issue.<br /> <br /> WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525<br /> amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]<br /> Call Trace:<br /> <br /> drm_file_free.part.0+0x1da/0x230 [drm]<br /> drm_close_helper.isra.0+0x65/0x70 [drm]<br /> drm_release+0x6a/0x120 [drm]<br /> amdgpu_drm_release+0x51/0x60 [amdgpu]<br /> __fput+0x9f/0x280<br /> ____fput+0xe/0x20<br /> task_work_run+0x67/0xa0<br /> do_exit+0x217/0x3c0<br /> do_group_exit+0x3b/0xb0<br /> get_signal+0x14a/0x8d0<br /> arch_do_signal_or_restart+0xde/0x100<br /> exit_to_user_mode_loop+0xc1/0x1a0<br /> exit_to_user_mode_prepare+0xf4/0x100<br /> syscall_exit_to_user_mode+0x17/0x40<br /> do_syscall_64+0x69/0xc0<br /> <br /> (cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)

In Grafana, an excessively long dashboard title or panel name will cause Chromium browsers to become unresponsive due to Improper Input Validation vulnerability in Grafana.<br /> This issue affects Grafana: before 11.6.2 and is fixed in 11.6.2 and higher.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mctp: Don&amp;#39;t access ifa_index when missing<br /> <br /> In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but<br /> only when the struct ifaddrmsg is provided. Otherwise it will be<br /> comparing to uninitialised memory - reproducible in the syzkaller case from<br /> dhcpd, or busybox "ip addr show".<br /> <br /> The kernel MCTP implementation has always filtered by ifa_index, so<br /> existing userspace programs expecting to dump MCTP addresses must<br /> already be passing a valid ifa_index value (either 0 or a real index).<br /> <br /> BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128<br /> mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128<br /> rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380<br /> rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824<br /> netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: k3-udma: Add missing locking<br /> <br /> Recent kernels complain about a missing lock in k3-udma.c when the lock<br /> validator is enabled:<br /> <br /> [ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238<br /> [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28<br /> [ 4.144867] Hardware name: pp-v12 (DT)<br /> [ 4.148648] Workqueue: events udma_check_tx_completion<br /> [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 4.160834] pc : udma_start.isra.0+0x34/0x238<br /> [ 4.165227] lr : udma_start.isra.0+0x30/0x238<br /> [ 4.169618] sp : ffffffc083cabcf0<br /> [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005<br /> [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000<br /> [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670<br /> [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030<br /> [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048<br /> [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001<br /> [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68<br /> [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8<br /> [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000<br /> [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000<br /> [ 4.244986] Call trace:<br /> [ 4.247463] udma_start.isra.0+0x34/0x238<br /> [ 4.251509] udma_check_tx_completion+0xd0/0xdc<br /> [ 4.256076] process_one_work+0x244/0x3fc<br /> [ 4.260129] process_scheduled_works+0x6c/0x74<br /> [ 4.264610] worker_thread+0x150/0x1dc<br /> [ 4.268398] kthread+0xd8/0xe8<br /> [ 4.271492] ret_from_fork+0x10/0x20<br /> [ 4.275107] irq event stamp: 220<br /> [ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50<br /> [ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50<br /> [ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc<br /> [ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28<br /> [ 4.311559] ---[ end trace 0000000000000000 ]---<br /> <br /> This commit adds the missing locking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: uclogic: Add NULL check in uclogic_input_configured()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> uclogic_input_configured() does not check for this case, which results<br /> in a NULL pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue.

Missing Authorization vulnerability in Cloudways Breeze breeze allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Breeze: from n/a through

Arbitrary file write as the OSV-SCALIBR user on the host system via a path traversal vulnerability when using OSV-SCALIBR&amp;#39;s unpack() function for container images. Particularly, when using the CLI flag --remote-image on untrusted container images.

The Recover WooCommerce Cart Abandonment, Newsletter, Email Marketing, Marketing Automation By FunnelKit plugin for WordPress is vulnerable to unauthorized arbitrary plugin installation due to a missing capability check on the install_or_activate_addon_plugins() function and a weak nonce hash in all versions up to, and including, 3.5.3. This makes it possible for unauthenticated attackers to install arbitrary plugins on the site that can be leveraged to further infect a vulnerable site.

The tarteaucitron.io WordPress plugin before 1.9.5 uses query parameters from YouTube oEmbed URLs without sanitizing these parameters correctly, which could allow users with the contributor role and above to perform Stored Cross-site Scripting attacks.