xamxte/cve-to-cwe huggingface dataset:
CVE-2025-10357: The Simple SEO WordPress plugin before 2.0.32 does not sanitise and escape some parameters when outputing them in the page, which could allow users with a role as low as contributor to perform Cross-Site Scripting attacks.
CVE-2025-8594: The Pz-LinkCard WordPress plugin before 2.5.7 does not validate a parameter before making a request to it, which could allow users with a role as low as Contributor to perform SSRF attack.
CVE-2025-11577: Clevo’s UEFI firmware update packages, including B10717.exe, inadvertently contained private signing keys used for Boot Guard and Boot Policy Manifest verification. The exposure of these keys could allow attackers to sign malicious firmware that appears trusted by affected systems, undermining the integrity of the early boot process.
CVE-2025-39970: In the Linux kernel, the following vulnerability has been resolved:  i40e: fix input validation logic for action_meta  Fix condition to check 'greater or equal' to prevent OOB dereference.
CVE-2025-39972: In the Linux kernel, the following vulnerability has been resolved:  i40e: fix idx validation in i40e_validate_queue_map  Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map().
CVE-2025-39973: In the Linux kernel, the following vulnerability has been resolved:  i40e: add validation for ring_len param  The `ring_len` parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation.  To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.
CVE-2025-39974: In the Linux kernel, the following vulnerability has been resolved:  tracing/osnoise: Fix slab-out-of-bounds in _parse_integer_limit()  When config osnoise cpus by write() syscall, the following KASAN splat may be observed:  BUG: KASAN: slab-out-of-bounds in _parse_integer_limit+0x103/0x130 Read of size 1 at addr ffff88810121e3a1 by task test/447 CPU: 1 UID: 0 PID: 447 Comm: test Not tainted 6.17.0-rc6-dirty #288 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x55/0x70  print_report+0xcb/0x610  kasan_report+0xb8/0xf0  _parse_integer_limit+0x103/0x130  bitmap_parselist+0x16d/0x6f0  osnoise_cpus_write+0x116/0x2d0  vfs_write+0x21e/0xcc0  ksys_write+0xee/0x1c0  do_syscall_64+0xa8/0x2a0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  </TASK>  This issue can be reproduced by below code:  const char *cpulist = "1"; int fd=open("/sys/kernel/debug/tracing/osnoise/cpus", O_WRONLY); write(fd, cpulist, strlen(cpulist));  Function bitmap_parselist() was called to parse cpulist, it require that the parameter 'buf' must be terminated with a '\0' or '\n'. Fix this issue by adding a '\0' to 'buf' in osnoise_cpus_write().
CVE-2025-39977: In the Linux kernel, the following vulnerability has been resolved:  futex: Prevent use-after-free during requeue-PI  syzbot managed to trigger the following race:     T1                               T2   futex_wait_requeue_pi()    futex_do_wait()      schedule()                                futex_requeue()                                  futex_proxy_trylock_atomic()                                    futex_requeue_pi_prepare()                                    requeue_pi_wake_futex()                                      futex_requeue_pi_complete()                                       /* preempt */           * timeout/ signal wakes T1 *     futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED    futex_hash_put()   // back to userland, on stack futex_q is garbage                                        /* back */                                      wake_up_state(q->task, TASK_NORMAL);  In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization.  This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section.  Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state().  A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated.  Read futex_q::task before updating the requeue state, use it for the following wakeup.
CVE-2025-39978: In the Linux kernel, the following vulnerability has been resolved:  octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()  This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node" and then dereferences it on the next line.  Two lines later, we take a mutex so I don't think this is an RCU safe region.  Re-order it to do the dereferences before queuing up the free.
CVE-2025-39979: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: fs, fix UAF in flow counter release  Fix a kernel trace [1] caused by releasing an HWS action of a local flow counter in mlx5_cmd_hws_delete_fte(), where the HWS action refcount and mutex were not initialized and the counter struct could already be freed when deleting the rule.  Fix it by adding the missing initializations and adding refcount for the local flow counter struct.  [1] Kernel log:  Call Trace:   <TASK>   dump_stack_lvl+0x34/0x48   mlx5_fs_put_hws_action.part.0.cold+0x21/0x94 [mlx5_core]   mlx5_fc_put_hws_action+0x96/0xad [mlx5_core]   mlx5_fs_destroy_fs_actions+0x8b/0x152 [mlx5_core]   mlx5_cmd_hws_delete_fte+0x5a/0xa0 [mlx5_core]   del_hw_fte+0x1ce/0x260 [mlx5_core]   mlx5_del_flow_rules+0x12d/0x240 [mlx5_core]   ? ttwu_queue_wakelist+0xf4/0x110   mlx5_ib_destroy_flow+0x103/0x1b0 [mlx5_ib]   uverbs_free_flow+0x20/0x50 [ib_uverbs]   destroy_hw_idr_uobject+0x1b/0x50 [ib_uverbs]   uverbs_destroy_uobject+0x34/0x1a0 [ib_uverbs]   uobj_destroy+0x3c/0x80 [ib_uverbs]   ib_uverbs_run_method+0x23e/0x360 [ib_uverbs]   ? uverbs_finalize_object+0x60/0x60 [ib_uverbs]   ib_uverbs_cmd_verbs+0x14f/0x2c0 [ib_uverbs]   ? do_tty_write+0x1a9/0x270   ? file_tty_write.constprop.0+0x98/0xc0   ? new_sync_write+0xfc/0x190   ib_uverbs_ioctl+0xd7/0x160 [ib_uverbs]   __x64_sys_ioctl+0x87/0xc0   do_syscall_64+0x59/0x90
CVE-2025-39980: In the Linux kernel, the following vulnerability has been resolved:  nexthop: Forbid FDB status change while nexthop is in a group  The kernel forbids the creation of non-FDB nexthop groups with FDB nexthops:   # ip nexthop add id 1 via 192.0.2.1 fdb  # ip nexthop add id 2 group 1  Error: Non FDB nexthop group cannot have fdb nexthops.  And vice versa:   # ip nexthop add id 3 via 192.0.2.2 dev dummy1  # ip nexthop add id 4 group 3 fdb  Error: FDB nexthop group can only have fdb nexthops.  However, as long as no routes are pointing to a non-FDB nexthop group, the kernel allows changing the type of a nexthop from FDB to non-FDB and vice versa:   # ip nexthop add id 5 via 192.0.2.2 dev dummy1  # ip nexthop add id 6 group 5  # ip nexthop replace id 5 via 192.0.2.2 fdb  # echo $?  0  This configuration is invalid and can result in a NPD [1] since FDB nexthops are not associated with a nexthop device:   # ip route add 198.51.100.1/32 nhid 6  # ping 198.51.100.1  Fix by preventing nexthop FDB status change while the nexthop is in a group:   # ip nexthop add id 7 via 192.0.2.2 dev dummy1  # ip nexthop add id 8 group 7  # ip nexthop replace id 7 via 192.0.2.2 fdb  Error: Cannot change nexthop FDB status while in a group.  [1] BUG: kernel NULL pointer dereference, address: 00000000000003c0 [...] Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:fib_lookup_good_nhc+0x1e/0x80 [...] Call Trace:  <TASK>  fib_table_lookup+0x541/0x650  ip_route_output_key_hash_rcu+0x2ea/0x970  ip_route_output_key_hash+0x55/0x80  __ip4_datagram_connect+0x250/0x330  udp_connect+0x2b/0x60  __sys_connect+0x9c/0xd0  __x64_sys_connect+0x18/0x20  do_syscall_64+0xa4/0x2a0  entry_SYSCALL_64_after_hwframe+0x4b/0x53
CVE-2025-39985: In the Linux kernel, the following vulnerability has been resolved:  can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow  Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU.  Unfortunately, because the mcba_usb driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example:    $ ip link set can0 mtu 9999  After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol:   socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))  to inject a malicious CAN XL frames. For example:   struct canxl_frame frame = {   .flags = 0xff,   .len = 2048,  };  The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks:    1. the skb->protocol is set to ETH_P_CANXL which is valid (the      function does not check the actual device capabilities).    2. the length is a valid CAN XL length.  And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame.  This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on these lines:   usb_msg.dlc = cf->len;   memcpy(usb_msg.data, cf->data, usb_msg.dlc);  Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs!  Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.
CVE-2025-39986: In the Linux kernel, the following vulnerability has been resolved:  can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow  Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU.  Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example:    $ ip link set can0 mtu 9999  After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol:   socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))  to inject a malicious CAN XL frames. For example:   struct canxl_frame frame = {   .flags = 0xff,   .len = 2048,  };  The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks:    1. the skb->protocol is set to ETH_P_CANXL which is valid (the      function does not check the actual device capabilities).    2. the length is a valid CAN XL length.  And so, sun4ican_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame.  This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on this line:   dlc = cf->len;  Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs a couple line below when doing:   for (i = 0; i < dlc; i++)   writel(cf->data[i], priv->base + (dreg + i * 4));  Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.
CVE-2025-39987: In the Linux kernel, the following vulnerability has been resolved:  can: hi311x: populate ndo_change_mtu() to prevent buffer overflow  Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU.  Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example:    $ ip link set can0 mtu 9999  After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol:   socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))  to inject a malicious CAN XL frames. For example:   struct canxl_frame frame = {   .flags = 0xff,   .len = 2048,  };  The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks:    1. the skb->protocol is set to ETH_P_CANXL which is valid (the      function does not check the actual device capabilities).    2. the length is a valid CAN XL length.  And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. The driver will consume frame->len as-is with no further checks.  This can result in a buffer overflow later on in hi3110_hw_tx() on this line:   memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,         frame->data, frame->len);  Here, frame->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs!  Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.
CVE-2025-39988: In the Linux kernel, the following vulnerability has been resolved:  can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow  Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU.  Unfortunately, because the etas_es58x driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example:    $ ip link set can0 mtu 9999  After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol:   socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));  to inject a malicious CAN XL frames. For example:   struct canxl_frame frame = {   .flags = 0xff,   .len = 2048,  };  The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks:    1. the skb->protocol is set to ETH_P_CANXL which is valid (the      function does not check the actual device capabilities).    2. the length is a valid CAN XL length.  And so, es58x_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN(FD) frame.  This can result in a buffer overflow. For example, using the es581.4 variant, the frame will be dispatched to es581_4_tx_can_msg(), go through the last check at the beginning of this function:   if (can_is_canfd_skb(skb))   return -EMSGSIZE;  and reach this line:   memcpy(tx_can_msg->data, cf->data, cf->len);  Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs!  Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU or CANFD_MTU (depending on the device capabilities). By fixing the root cause, this prevents the buffer overflow.
CVE-2025-39990: In the Linux kernel, the following vulnerability has been resolved:  bpf: Check the helper function is valid in get_helper_proto  kernel test robot reported verifier bug [1] where the helper func pointer could be NULL due to disabled config option.  As Alexei suggested we could check on that in get_helper_proto directly. Marking tail_call helper func with BPF_PTR_POISON, because it is unused by design.    [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com
CVE-2025-39991: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()  If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is not allocated, then fw is dereferenced to be passed to ath11k_err function.  Replace fw->size by m3_len.  Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-39992: In the Linux kernel, the following vulnerability has been resolved:  mm: swap: check for stable address space before operating on the VMA  It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS:  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info:   ESR = 0x0000000096000005   EC = 0x25: DABT (current EL), IL = 32 bits   SET = 0, FnV = 0   EA = 0, S1PTW = 0   FSC = 0x05: level 1 translation fault  The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap())   swapoff(unuse_mm) ---------------                         ----------------- 1) Identical mtree is built using    __mt_dup().  2) copy_pte_range()-->  copy_nonpresent_pte():        The dst mm is added into the     mmlist to be visible to the     swapoff operation.  3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap().           4) swapoff is tried on the      'mm' added to the 'mmlist' as      part of the 2.           5) unuse_mm(), that iterates      through the vma's of this 'mm'      will hit the non-NULL zero entry      and operating on this zero entry      as a vma is resulting into the      oops.  The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1].  A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap().  Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.
CVE-2025-39993: In the Linux kernel, the following vulnerability has been resolved:  media: rc: fix races with imon_disconnect()  Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465  CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace:  <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.  Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.  As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.  Thread 1 vfd_write                      Thread 2 imon_disconnect                                         ...                                         if                                           usb_put_dev(ictx->usbdev_intf0)                                         else                                           usb_put_dev(ictx->usbdev_intf1) ... while   send_packet     if       pipe = usb_sndintpipe(         ictx->usbdev_intf0) UAF     else       pipe = usb_sndctrlpipe(         ictx->usbdev_intf0, 0) UAF  Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.  Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.  Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-39994: In the Linux kernel, the following vulnerability has been resolved:  media: tuner: xc5000: Fix use-after-free in xc5000_release  The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv.  A typical race condition is illustrated below:  CPU 0 (release thread)                 | CPU 1 (delayed work callback) xc5000_release()                       | xc5000_do_timer_sleep()   cancel_delayed_work()                |   hybrid_tuner_release_state(priv)     |     kfree(priv)                        |                                        |   priv = container_of() // UAF  Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated.  A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here.  This bug was initially identified through static analysis.  [hverkuil: fix typo in Subject: tunner -> tuner]
CVE-2025-39997: In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free  The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at removal") patched a UAF issue caused by the error timer.  However, because the error timer kill added in this patch occurs after the endpoint delete, a race condition to UAF still occurs, albeit rarely.  Additionally, since kill-cleanup for urb is also missing, freed memory can be accessed in interrupt context related to urb, which can cause UAF.  Therefore, to prevent this, error timer and urb must be killed before freeing the heap memory.