Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Disable MACsec offload for uplink representor profile<br /> <br /> MACsec offload is not supported in switchdev mode for uplink<br /> representors. When switching to the uplink representor profile, the<br /> MACsec offload feature must be cleared from the netdevice&amp;#39;s features.<br /> <br /> If left enabled, attempts to add offloads result in a null pointer<br /> dereference, as the uplink representor does not support MACsec offload<br /> even though the feature bit remains set.<br /> <br /> Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().<br /> <br /> Kernel log:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]<br /> CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__mutex_lock+0x128/0x1dd0<br /> Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff<br /> RSP: 0018:ffff888147a4f160 EFLAGS: 00010206<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001<br /> RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078<br /> RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000<br /> FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? die_addr+0x3d/0xa0<br /> ? exc_general_protection+0x144/0x220<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? __mutex_lock+0x128/0x1dd0<br /> ? lockdep_set_lock_cmp_fn+0x190/0x190<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? mutex_lock_io_nested+0x1ae0/0x1ae0<br /> ? lock_acquire+0x1c2/0x530<br /> ? macsec_upd_offload+0x145/0x380<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? kasan_save_stack+0x30/0x40<br /> ? kasan_save_stack+0x20/0x40<br /> ? kasan_save_track+0x10/0x30<br /> ? __kasan_kmalloc+0x77/0x90<br /> ? __kmalloc_noprof+0x249/0x6b0<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]<br /> macsec_update_offload+0x26c/0x820<br /> ? macsec_set_mac_address+0x4b0/0x4b0<br /> ? lockdep_hardirqs_on_prepare+0x284/0x400<br /> ? _raw_spin_unlock_irqrestore+0x47/0x50<br /> macsec_upd_offload+0x2c8/0x380<br /> ? macsec_update_offload+0x820/0x820<br /> ? __nla_parse+0x22/0x30<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240<br /> genl_family_rcv_msg_doit+0x1cc/0x2a0<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240<br /> ? cap_capable+0xd4/0x330<br /> genl_rcv_msg+0x3ea/0x670<br /> ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0<br /> ? lockdep_set_lock_cmp_fn+0x190/0x190<br /> ? macsec_update_offload+0x820/0x820<br /> netlink_rcv_skb+0x12b/0x390<br /> ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0<br /> ? netlink_ack+0xd80/0xd80<br /> ? rwsem_down_read_slowpath+0xf90/0xf90<br /> ? netlink_deliver_tap+0xcd/0xac0<br /> ? netlink_deliver_tap+0x155/0xac0<br /> ? _copy_from_iter+0x1bb/0x12c0<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x440/0x700<br /> ? netlink_attachskb+0x760/0x760<br /> ? lock_acquire+0x1c2/0x530<br /> ? __might_fault+0xbb/0x170<br /> netlink_sendmsg+0x749/0xc10<br /> ? netlink_unicast+0x700/0x700<br /> ? __might_fault+0xbb/0x170<br /> ? netlink_unicast+0x700/0x700<br /> __sock_sendmsg+0xc5/0x190<br /> ____sys_sendmsg+0x53f/0x760<br /> ? import_iovec+0x7/0x10<br /> ? kernel_sendmsg+0x30/0x30<br /> ? __copy_msghdr+0x3c0/0x3c0<br /> ? filter_irq_stacks+0x90/0x90<br /> ? stack_depot_save_flags+0x28/0xa30<br /> ___sys_sen<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tls: fix kernel panic when alloc_page failed<br /> <br /> We cannot set frag_list to NULL pointer when alloc_page failed.<br /> It will be used in tls_strp_check_queue_ok when the next time<br /> tls_strp_read_sock is called.<br /> <br /> This is because we don&amp;#39;t reset full_len in tls_strp_flush_anchor_copy()<br /> so the recv path will try to continue handling the partial record<br /> on the next call but we dettached the rcvq from the frag list.<br /> Alternative fix would be to reset full_len.<br /> <br /> Unable to handle kernel NULL pointer dereference<br /> at virtual address 0000000000000028<br /> Call trace:<br /> tls_strp_check_rcv+0x128/0x27c<br /> tls_strp_data_ready+0x34/0x44<br /> tls_data_ready+0x3c/0x1f0<br /> tcp_data_ready+0x9c/0xe4<br /> tcp_data_queue+0xf6c/0x12d0<br /> tcp_rcv_established+0x52c/0x798

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: fix memory leak in error handling path of idxd_alloc<br /> <br /> Memory allocated for idxd is not freed if an error occurs during<br /> idxd_alloc(). To fix it, free the allocated memory in the reverse order<br /> of allocation before exiting the function in case of an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:634<br /> strlen+0x93/0xa0 lib/string.c:420<br /> __fortify_strlen include/linux/fortify-string.h:268 [inline]<br /> get_kobj_path_length lib/kobject.c:118 [inline]<br /> kobject_get_path+0x3f/0x2a0 lib/kobject.c:158<br /> kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545<br /> ib_register_device drivers/infiniband/core/device.c:1472 [inline]<br /> ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393<br /> rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552<br /> rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550<br /> rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225<br /> nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796<br /> rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195<br /> rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]<br /> netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339<br /> netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg net/socket.c:727 [inline]<br /> ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620<br /> __sys_sendmsg+0x16d/0x220 net/socket.c:2652<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> This problem is similar to the problem that the<br /> commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")<br /> fixes.<br /> <br /> The root cause is: the function ib_device_rename() renames the name with<br /> lock. But in the function kobject_uevent(), this name is accessed without<br /> lock protection at the same time.<br /> <br /> The solution is to add the lock protection when this name is accessed in<br /> the function kobject_uevent().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Refactor remove call with idxd_cleanup() helper<br /> <br /> The idxd_cleanup() helper cleans up perfmon, interrupts, internals and<br /> so on. Refactor remove call with the idxd_cleanup() helper to avoid code<br /> duplication. Note, this also fixes the missing put_device() for idxd<br /> groups, enginces and wqs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request<br /> <br /> Make sure that n_channels is set after allocating the<br /> struct cfg80211_registered_device::int_scan_req member. Seen with<br /> syzkaller:<br /> <br /> UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5<br /> index 0 is out of range for type &amp;#39;struct ieee80211_channel *[] __counted_by(n_channels)&amp;#39; (aka &amp;#39;struct ieee80211_channel *[]&amp;#39;)<br /> <br /> This was missed in the initial conversions because I failed to locate<br /> the allocation likely due to the "sizeof(void *)" not matching the<br /> "channels" array type.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: bpf_iter_scx_dsq_new() should always initialize iterator<br /> <br /> BPF programs may call next() and destroy() on BPF iterators even after new()<br /> returns an error value (e.g. bpf_for_each() macro ignores error returns from<br /> new()). bpf_iter_scx_dsq_new() could leave the iterator in an uninitialized<br /> state after an error return causing bpf_iter_scx_dsq_next() to dereference<br /> garbage data. Make bpf_iter_scx_dsq_new() always clear $kit-&gt;dsq so that<br /> next() and destroy() become noops.

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.