xamxte/cve-to-cwe huggingface dataset:
CVE-2025-38305: In the Linux kernel, the following vulnerability has been resolved:  ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()  There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use.  However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store().  ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:  ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:  ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415  but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:  n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215  other info that might help us debug this:  Possible unsafe locking scenario:         CPU0        ----   lock(&ptp->n_vclocks_mux);   lock(&ptp->n_vclocks_mux);   *** DEADLOCK *** .... ============================================  The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use().  The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks.  Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking.
CVE-2025-38310: In the Linux kernel, the following vulnerability has been resolved:  seg6: Fix validation of nexthop addresses  The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one.  Fix by validating that the provided length exactly matches the specified one.
CVE-2025-38343: In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7996: drop fragments with multicast or broadcast RA  IEEE 802.11 fragmentation can only be applied to unicast frames. Therefore, drop fragments with multicast or broadcast RA. This patch addresses vulnerabilities such as CVE-2020-26145.
CVE-2025-38347: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on ino and xnid  syzbot reported a f2fs bug as below:  INFO: task syz-executor140:5308 blocked for more than 143 seconds.       Not tainted 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor140 state:D stack:24016 pid:5308  tgid:5308  ppid:5306   task_flags:0x400140 flags:0x00000006 Call Trace:  <TASK>  context_switch kernel/sched/core.c:5378 [inline]  __schedule+0x190e/0x4c90 kernel/sched/core.c:6765  __schedule_loop kernel/sched/core.c:6842 [inline]  schedule+0x14b/0x320 kernel/sched/core.c:6857  io_schedule+0x8d/0x110 kernel/sched/core.c:7690  folio_wait_bit_common+0x839/0xee0 mm/filemap.c:1317  __folio_lock mm/filemap.c:1664 [inline]  folio_lock include/linux/pagemap.h:1163 [inline]  __filemap_get_folio+0x147/0xb40 mm/filemap.c:1917  pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87  find_get_page_flags include/linux/pagemap.h:842 [inline]  f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776  __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463  read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306  lookup_all_xattrs fs/f2fs/xattr.c:355 [inline]  f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533  __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179  f2fs_acl_create fs/f2fs/acl.c:375 [inline]  f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418  f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539  f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666  f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765  f2fs_do_add_link+0x28c/0x3a0 fs/f2fs/dir.c:808  f2fs_add_link fs/f2fs/f2fs.h:3616 [inline]  f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766  vfs_mknod+0x36d/0x3b0 fs/namei.c:4191  unix_bind_bsd net/unix/af_unix.c:1286 [inline]  unix_bind+0x563/0xe30 net/unix/af_unix.c:1379  __sys_bind_socket net/socket.c:1817 [inline]  __sys_bind+0x1e4/0x290 net/socket.c:1848  __do_sys_bind net/socket.c:1853 [inline]  __se_sys_bind net/socket.c:1851 [inline]  __x64_sys_bind+0x7a/0x90 net/socket.c:1851  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Let's dump and check metadata of corrupted inode, it shows its xattr_nid is the same to its i_ino.  dump.f2fs -i 3 chaseyu.img.raw i_xattr_nid                             [0x       3 : 3]  So that, during mknod in the corrupted directory, it tries to get and lock inode page twice, result in deadlock.  - f2fs_mknod  - f2fs_add_inline_entry   - f2fs_get_inode_page --- lock dir's inode page    - f2fs_init_acl     - f2fs_acl_create(dir,..)      - __f2fs_get_acl       - f2fs_getxattr        - lookup_all_xattrs         - __get_node_page --- try to lock dir's inode page  In order to fix this, let's add sanity check on ino and xnid.
CVE-2025-2942: The Order Delivery Date WordPress plugin before 12.6.0 discloses arbitrary post title (such as from draft and private posts) via an unauthenticated AJAX action, allowing attackers to retrieve such information
CVE-2025-7026: A vulnerability in the Software SMI handler (SwSmiInputValue 0xB2) allows a local attacker to control the RBX register, which is used as an unchecked pointer in the CommandRcx0 function. If the contents at RBX match certain expected values (e.g., '$DB$' or '2DB$'), the function performs arbitrary writes to System Management RAM (SMRAM), leading to potential privilege escalation to System Management Mode (SMM) and persistent firmware compromise.
CVE-2025-7027: A vulnerability in the Software SMI handler (SwSmiInputValue 0xB2) allows a local attacker to control both the read and write addresses used by the CommandRcx1 function. The write target is derived from an unvalidated UEFI NVRAM variable (SetupXtuBufferAddress), while the write content is read from an attacker-controlled pointer based on the RBX register. This dual-pointer dereference enables arbitrary memory writes within System Management RAM (SMRAM), leading to potential SMM privilege escalation and firmware compromise.
CVE-2025-7028: A vulnerability in the Software SMI handler (SwSmiInputValue 0x20) allows a local attacker to supply a crafted pointer (FuncBlock) through RBX and RCX register values. This pointer is passed unchecked into multiple flash management functions (ReadFlash, WriteFlash, EraseFlash, and GetFlashInfo) that dereference both the structure and its nested members, such as BufAddr. This enables arbitrary read/write access to System Management RAM (SMRAM), allowing an attacker to corrupt firmware memory, exfiltrate SMRAM content via flash, or install persistent implants.
CVE-2025-7029: A vulnerability in the Software SMI handler (SwSmiInputValue 0xB2) allows a local attacker to control the RBX register, which is used to derive pointers (OcHeader, OcData) passed into power and thermal configuration logic. These buffers are not validated before performing multiple structured memory writes based on OcSetup NVRAM values, enabling arbitrary SMRAM corruption and potential SMM privilege escalation.
CVE-2025-30402: A heap-buffer-overflow vulnerability in the loading of ExecuTorch methods can cause the runtime to crash and potentially result in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit 93b1a0c15f7eda49b2bc46b5b4c49557b4e9810f
CVE-2025-30403: A heap-buffer-overflow vulnerability is possible in mvfst via a specially crafted message during a QUIC session. This issue affects mvfst versions prior to v2025.07.07.00.
CVE-2024-26293: The Avid Nexis Agent uses a vulnerable gSOAP version. An undocumented vulnerability impacting gSOAP v2.8 makes the application vulnerable to an Unauthenticated Path Traversal vulnerability. This issue affects Avid NEXIS E-series: before 2025.5.1; Avid NEXIS F-series: before 2025.5.1; Avid NEXIS PRO+: before 2025.5.1; System Director Appliance (SDA+): before 2025.5.1.
CVE-2025-40913: Net::Dropbear versions through 0.16 for Perl contains a dependency that may be susceptible to an integer overflow.  Net::Dropbear embeds a version of the libtommath library that is susceptible to an integer overflow associated with CVE-2023-36328.
CVE-2025-4302: The Stop User Enumeration WordPress plugin before version 1.7.3 blocks REST API /wp-json/wp/v2/users/ requests for non-authorized users. However, this can be bypassed by URL-encoding the API path.
CVE-2025-23269: NVIDIA Jetson Linux contains a vulnerability in the kernel where an attacker may cause an exposure of sensitive information due to a shared microarchitectural predictor state that influences transient execution. A successful exploit of this vulnerability may lead to information disclosure.
CVE-2025-38351: In the Linux kernel, the following vulnerability has been resolved:  KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush  In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated.  However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD.  While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():    invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000   WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482   invvpid_error+0x91/0xa0 [kvm_intel]   Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse   CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)   RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]   Call Trace:     vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]     kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]     kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]  Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored.  While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way.  Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure.  Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.
CVE-2025-6174: The Qwizcards | online quizzes and flashcards WordPress plugin through 3.9.4 does not sanitise and escape the "_stylesheet" parameter before outputting it back in the page, leading to a Reflected Cross-Site Scripting which could be used against high privilege users such as admin or any other user.
CVE-2025-7022: The My Reservation System WordPress plugin through 2.3 does not sanitise and escape a parameter before outputting it back in the page, leading to a Reflected Cross-Site Scripting which could be used against high privilege users such as admin.
CVE-2025-38354: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/gpu: Fix crash when throttling GPU immediately during boot  There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash:    Unable to handle kernel paging request at virtual address 0000000000014110   pc : a6xx_gpu_busy+0x1c/0x58 [msm]   lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]   Call trace:    a6xx_gpu_busy+0x1c/0x58 [msm] (P)    devfreq_simple_ondemand_func+0x3c/0x150    devfreq_update_target+0x44/0xd8    qos_max_notifier_call+0x30/0x84    blocking_notifier_call_chain+0x6c/0xa0    pm_qos_update_target+0xd0/0x110    freq_qos_apply+0x3c/0x74    apply_constraint+0x88/0x148    __dev_pm_qos_update_request+0x7c/0xcc    dev_pm_qos_update_request+0x38/0x5c    devfreq_cooling_set_cur_state+0x98/0xf0    __thermal_cdev_update+0x64/0xb4    thermal_cdev_update+0x4c/0x58    step_wise_manage+0x1f0/0x318    __thermal_zone_device_update+0x278/0x424    __thermal_cooling_device_register+0x2bc/0x308    thermal_of_cooling_device_register+0x10/0x1c    of_devfreq_cooling_register_power+0x240/0x2bc    of_devfreq_cooling_register+0x14/0x20    msm_devfreq_init+0xc4/0x1a0 [msm]    msm_gpu_init+0x304/0x574 [msm]    adreno_gpu_init+0x1c4/0x2e0 [msm]    a6xx_gpu_init+0x5c8/0x9c8 [msm]    adreno_bind+0x2a8/0x33c [msm]    ...  At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msm_devfreq_get_dev_status() will end up accessing GMU registers, causing the crash.  Fix this by setting df->suspended correctly during initialization.  Patchwork: https://patchwork.freedesktop.org/patch/650772/
CVE-2025-38355: In the Linux kernel, the following vulnerability has been resolved:  drm/xe: Process deferred GGTT node removals on device unwind  While we are indirectly draining our dedicated workqueue ggtt->wq that we use to complete asynchronous removal of some GGTT nodes, this happends as part of the managed-drm unwinding (ggtt_fini_early), which could be later then manage-device unwinding, where we could already unmap our MMIO/GMS mapping (mmio_fini).  This was recently observed during unsuccessful VF initialization:   [ ] xe 0000:00:02.1: probe with driver xe failed with error -62  [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes)  [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes)  [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes)  [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes)  [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes)  [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes)  [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes)  [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin  [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes)  [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes)  [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes)  [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes)  and this was leading to:   [ ] BUG: unable to handle page fault for address: ffffc900058162a0  [ ] #PF: supervisor write access in kernel mode  [ ] #PF: error_code(0x0002) - not-present page  [ ] Oops: Oops: 0002 [#1] SMP NOPTI  [ ] Tainted: [W]=WARN  [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe]  [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe]  [ ] Call Trace:  [ ]  <TASK>  [ ]  xe_ggtt_clear+0xb0/0x270 [xe]  [ ]  ggtt_node_remove+0xbb/0x120 [xe]  [ ]  ggtt_node_remove_work_func+0x30/0x50 [xe]  [ ]  process_one_work+0x22b/0x6f0  [ ]  worker_thread+0x1e8/0x3d  Add managed-device action that will explicitly drain the workqueue with all pending node removals prior to releasing MMIO/GSM mapping.  (cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)
CVE-2025-38361: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check dce_hwseq before dereferencing it  [WHAT]  hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used.  (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)
CVE-2025-38366: In the Linux kernel, the following vulnerability has been resolved:  LoongArch: KVM: Check validity of "num_cpu" from user space  The maximum supported cpu number is EIOINTC_ROUTE_MAX_VCPUS about irqchip EIOINTC, here add validation about cpu number to avoid array pointer overflow.
CVE-2025-38372: In the Linux kernel, the following vulnerability has been resolved:  RDMA/mlx5: Fix unsafe xarray access in implicit ODP handling  __xa_store() and __xa_erase() were used without holding the proper lock, which led to a lockdep warning due to unsafe RCU usage.  This patch replaces them with xa_store() and xa_erase(), which perform the necessary locking internally.    =============================   WARNING: suspicious RCPU usage   6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted   -----------------------------   ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage!    other info that might help us debug this:    rcu_scheduler_active = 2, debug_locks = 1   3 locks held by kworker/u136:0/219:       at: process_one_work+0xbe4/0x15f0       process_one_work+0x75c/0x15f0       pagefault_mr+0x9a5/0x1390 [mlx5_ib]    stack backtrace:   CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted   6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS   rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014   Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]   Call Trace:    dump_stack_lvl+0xa8/0xc0    lockdep_rcu_suspicious+0x1e6/0x260    xas_create+0xb8a/0xee0    xas_store+0x73/0x14c0    __xa_store+0x13c/0x220    ? xa_store_range+0x390/0x390    ? spin_bug+0x1d0/0x1d0    pagefault_mr+0xcb5/0x1390 [mlx5_ib]    ? _raw_spin_unlock+0x1f/0x30    mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib]    ? lockdep_hardirqs_on_prepare+0x400/0x400    ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib]    process_one_work+0x7db/0x15f0    ? pwq_dec_nr_in_flight+0xda0/0xda0    ? assign_work+0x168/0x240    worker_thread+0x57d/0xcd0    ? rescuer_thread+0xc40/0xc40    kthread+0x3b3/0x800    ? kthread_is_per_cpu+0xb0/0xb0    ? lock_downgrade+0x680/0x680    ? do_raw_spin_lock+0x12d/0x270    ? spin_bug+0x1d0/0x1d0    ? finish_task_switch.isra.0+0x284/0x9e0    ? lockdep_hardirqs_on_prepare+0x284/0x400    ? kthread_is_per_cpu+0xb0/0xb0    ret_from_fork+0x2d/0x70    ? kthread_is_per_cpu+0xb0/0xb0    ret_from_fork_asm+0x11/0x20
CVE-2025-38392: In the Linux kernel, the following vulnerability has been resolved:  idpf: convert control queue mutex to a spinlock  With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated on module load:  [  324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578 [  324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager [  324.701689] preempt_count: 201, expected: 0 [  324.701693] RCU nest depth: 0, expected: 0 [  324.701697] 2 locks held by NetworkManager/1582: [  324.701702]  #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0 [  324.701730]  #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870 [  324.701749] Preemption disabled at: [  324.701752] [<ffffffff9cd23b9d>] __dev_open+0x3dd/0x870 [  324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary) [  324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022 [  324.701774] Call Trace: [  324.701777]  <TASK> [  324.701779]  dump_stack_lvl+0x5d/0x80 [  324.701788]  ? __dev_open+0x3dd/0x870 [  324.701793]  __might_resched.cold+0x1ef/0x23d <..> [  324.701818]  __mutex_lock+0x113/0x1b80 <..> [  324.701917]  idpf_ctlq_clean_sq+0xad/0x4b0 [idpf] [  324.701935]  ? kasan_save_track+0x14/0x30 [  324.701941]  idpf_mb_clean+0x143/0x380 [idpf] <..> [  324.701991]  idpf_send_mb_msg+0x111/0x720 [idpf] [  324.702009]  idpf_vc_xn_exec+0x4cc/0x990 [idpf] [  324.702021]  ? rcu_is_watching+0x12/0xc0 [  324.702035]  idpf_add_del_mac_filters+0x3ed/0xb50 [idpf] <..> [  324.702122]  __hw_addr_sync_dev+0x1cf/0x300 [  324.702126]  ? find_held_lock+0x32/0x90 [  324.702134]  idpf_set_rx_mode+0x317/0x390 [idpf] [  324.702152]  __dev_open+0x3f8/0x870 [  324.702159]  ? __pfx___dev_open+0x10/0x10 [  324.702174]  __dev_change_flags+0x443/0x650 <..> [  324.702208]  netif_change_flags+0x80/0x160 [  324.702218]  do_setlink.isra.0+0x16a0/0x3960 <..> [  324.702349]  rtnl_newlink+0x12fd/0x21e0  The sequence is as follows:  rtnl_newlink()->  __dev_change_flags()->  __dev_open()->  dev_set_rx_mode() - >  # disables BH and grabs "dev->addr_list_lock"  idpf_set_rx_mode() ->  # proceed only if VIRTCHNL2_CAP_MACFILTER is ON  __dev_uc_sync() ->  idpf_add_mac_filter ->  idpf_add_del_mac_filters ->  idpf_send_mb_msg() ->  idpf_mb_clean() ->  idpf_ctlq_clean_sq()   # mutex_lock(cq_lock)  Fix by converting cq_lock to a spinlock. All operations under the new lock are safe except freeing the DMA memory, which may use vunmap(). Fix by requesting a contiguous physical memory for the DMA mapping.
CVE-2025-38403: In the Linux kernel, the following vulnerability has been resolved:  vsock/vmci: Clear the vmci transport packet properly when initializing it  In vmci_transport_packet_init memset the vmci_transport_packet before populating the fields to avoid any uninitialised data being left in the structure.
CVE-2025-38412: In the Linux kernel, the following vulnerability has been resolved:  platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks  After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.
CVE-2025-38425: In the Linux kernel, the following vulnerability has been resolved:  i2c: tegra: check msg length in SMBUS block read  For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes.
CVE-2025-38426: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Add basic validation for RAS header  If RAS header read from EEPROM is corrupted, it could result in trying to allocate huge memory for reading the records. Add some validation to header fields.