xamxte/cve-to-cwe huggingface dataset:
CVE-2025-68308: In the Linux kernel, the following vulnerability has been resolved:  can: kvaser_usb: leaf: Fix potential infinite loop in command parsers  The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary.  The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function.  However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic.  This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.
CVE-2025-68309: In the Linux kernel, the following vulnerability has been resolved:  PCI/AER: Fix NULL pointer access by aer_info  The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info->xxx will result in kernel panic. Fix it.
CVE-2025-68312: In the Linux kernel, the following vulnerability has been resolved:  usbnet: Prevents free active kevent  The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here.  2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed.  The solution to this problem is to cancel the kevent before executing free_netdev().
CVE-2025-68319: In the Linux kernel, the following vulnerability has been resolved:  netconsole: Acquire su_mutex before navigating configs hierarchy  There is a race between operations that iterate over the userdata cg_children list and concurrent add/remove of userdata items through configfs. The update_userdata() function iterates over the nt->userdata_group.cg_children list, and count_extradata_entries() also iterates over this same list to count nodes.  Quoting from Documentation/filesystems/configfs.rst: > A subsystem can navigate the cg_children list and the ci_parent pointer > to see the tree created by the subsystem.  This can race with configfs' > management of the hierarchy, so configfs uses the subsystem mutex to > protect modifications.  Whenever a subsystem wants to navigate the > hierarchy, it must do so under the protection of the subsystem > mutex.  Without proper locking, if a userdata item is added or removed concurrently while these functions are iterating, the list can be accessed in an inconsistent state. For example, the list_for_each() loop can reach a node that is being removed from the list by list_del_init() which sets the nodes' .next pointer to point to itself, so the loop will never end (or reach the WARN_ON_ONCE in update_userdata() ).  Fix this by holding the configfs subsystem mutex (su_mutex) during all operations that iterate over cg_children. This includes: - userdatum_value_store() which calls update_userdata() to iterate over   cg_children - All sysdata_*_enabled_store() functions which call   count_extradata_entries() to iterate over cg_children  The su_mutex must be acquired before dynamic_netconsole_mutex to avoid potential lock ordering issues, as configfs operations may already hold su_mutex when calling into our code.
CVE-2025-68320: In the Linux kernel, the following vulnerability has been resolved:  lan966x: Fix sleeping in atomic context  The following warning was seen when we try to connect using ssh to the device.  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear preempt_count: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G        W           6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE Tainted: [W]=WARN Hardware name: Generic DT based system Call trace:  unwind_backtrace from show_stack+0x10/0x14  show_stack from dump_stack_lvl+0x7c/0xac  dump_stack_lvl from __might_resched+0x16c/0x2b0  __might_resched from __mutex_lock+0x64/0xd34  __mutex_lock from mutex_lock_nested+0x1c/0x24  mutex_lock_nested from lan966x_stats_get+0x5c/0x558  lan966x_stats_get from dev_get_stats+0x40/0x43c  dev_get_stats from dev_seq_printf_stats+0x3c/0x184  dev_seq_printf_stats from dev_seq_show+0x10/0x30  dev_seq_show from seq_read_iter+0x350/0x4ec  seq_read_iter from seq_read+0xfc/0x194  seq_read from proc_reg_read+0xac/0x100  proc_reg_read from vfs_read+0xb0/0x2b0  vfs_read from ksys_read+0x6c/0xec  ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0:                   00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8  It seems that we are using a mutex in a atomic context which is wrong. Change the mutex with a spinlock.
CVE-2025-68324: In the Linux kernel, the following vulnerability has been resolved:  scsi: imm: Fix use-after-free bug caused by unfinished delayed work  The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands.  When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated.  However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory.  The race condition can occur as follows:  CPU 0(detach thread)   | CPU 1                        | imm_queuecommand()                        |   imm_queuecommand_lck() imm_detach()           |     schedule_delayed_work()   kfree(dev) //FREE    | imm_interrupt()                        |   dev = container_of(...) //USE                            dev-> //USE  Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.
CVE-2025-68325: In the Linux kernel, the following vulnerability has been resolved:  net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop  In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc).  This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN.  To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.
CVE-2025-13307: The Ocean Modal Window WordPress plugin before 2.3.3 is vulnerable to Remote Code Execution via the modal display logic. These modals can be displayed under user-controlled conditions that Editors and Administrators can set (edit_pages capability). The conditions are then executed as part of an eval statement executed on every site page. This leads to remote code execution.
CVE-2025-12820: The Pure WC Variation Swatches WordPress plugin through 1.1.7 does not have an authorization check when updating its settings, which could allow any authenticated users to update them.
CVE-2025-68326: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/guc: Fix stack_depot usage  Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack:   [] BUG: kernel NULL pointer dereference, address: 0000000000000000  [] Workqueue:  drm_sched_run_job_work [gpu_sched]  [] RIP: 0010:stack_depot_save_flags+0x172/0x870  [] Call Trace:  []  <TASK>  []  fast_req_track+0x58/0xb0 [xe]  (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)
CVE-2025-68330: In the Linux kernel, the following vulnerability has been resolved:  iio: accel: bmc150: Fix irq assumption regression  The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts:  Unable to handle kernel NULL pointer dereference at virtual   address 00000001 when read  PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4  This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why.  Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.
CVE-2025-68331: In the Linux kernel, the following vulnerability has been resolved:  usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer  When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed.  The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed.  This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs().  The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().
CVE-2025-68335: In the Linux kernel, the following vulnerability has been resolved:  comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()  Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems from the fact that in case of early device detach via pcl818_detach(), subdevice dev->read_subdev may not have initialized its pointer to &struct comedi_async as intended. Thus, any such dereferencing of &s->async->cmd will lead to general protection fault and kernel crash.  Mitigate this problem by removing a call to pcl818_ai_cancel() from pcl818_detach() altogether. This way, if the subdevice setups its support for async commands, everything async-related will be handled via subdevice's own ->cancel() function in comedi_device_detach_locked() even before pcl818_detach(). If no support for asynchronous commands is provided, there is no need to cancel anything either.  [1] Syzbot crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762 ... Call Trace:  <TASK>  pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115  comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207  do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline]  comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:597 [inline] ...
CVE-2025-68336: In the Linux kernel, the following vulnerability has been resolved:  locking/spinlock/debug: Fix data-race in do_raw_write_lock  KCSAN reports:  BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lock  write (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1:  do_raw_write_lock+0x120/0x204  _raw_write_lock_irq  do_exit  call_usermodehelper_exec_async  ret_from_fork  read to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0:  do_raw_write_lock+0x88/0x204  _raw_write_lock_irq  do_exit  call_usermodehelper_exec_async  ret_from_fork  value changed: 0xffffffff -> 0x00000001  Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111  Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") has adressed most of these races, but seems to be not consistent/not complete.  >From do_raw_write_lock() only debug_write_lock_after() part has been converted to WRITE_ONCE(), but not debug_write_lock_before() part. Do it now.
CVE-2025-68337: In the Linux kernel, the following vulnerability has been resolved:  jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted  There's issue when file system corrupted: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1289! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0 RSP: 0018:ffff888117aafa30 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534 RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010 RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028 R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0 Call Trace:  <TASK>  __ext4_journal_get_create_access+0x42/0x170  ext4_getblk+0x319/0x6f0  ext4_bread+0x11/0x100  ext4_append+0x1e6/0x4a0  ext4_init_new_dir+0x145/0x1d0  ext4_mkdir+0x326/0x920  vfs_mkdir+0x45c/0x740  do_mkdirat+0x234/0x2f0  __x64_sys_mkdir+0xd6/0x120  do_syscall_64+0x5f/0xfa0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  The above issue occurs with us in errors=continue mode when accompanied by storage failures. There have been many inconsistencies in the file system data. In the case of file system data inconsistency, for example, if the block bitmap of a referenced block is not set, it can lead to the situation where a block being committed is allocated and used again. As a result, the following condition will not be satisfied then trigger BUG_ON. Of course, it is entirely possible to construct a problematic image that can trigger this BUG_ON through specific operations. In fact, I have constructed such an image and easily reproduced this issue. Therefore, J_ASSERT() holds true only under ideal conditions, but it may not necessarily be satisfied in exceptional scenarios. Using J_ASSERT() directly in abnormal situations would cause the system to crash, which is clearly not what we want. So here we directly trigger a JBD abort instead of immediately invoking BUG_ON.
CVE-2025-68338: In the Linux kernel, the following vulnerability has been resolved:  net: dsa: microchip: Don't free uninitialized ksz_irq  If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains.  Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.
CVE-2025-68341: In the Linux kernel, the following vulnerability has been resolved:  veth: reduce XDP no_direct return section to fix race  As explain in commit fa349e396e48 ("veth: Fix race with AF_XDP exposing old or uninitialized descriptors") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance.  The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested.  Prior to commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context.  Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().
CVE-2025-68342: In the Linux kernel, the following vulnerability has been resolved:  can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data  The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping).  Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received.  [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]
CVE-2025-68343: In the Linux kernel, the following vulnerability has been resolved:  can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header  The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback().  Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it.  To resubmit the URB, do not dereference the pointer chain "dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since "urb->context" contains "parent", it is always defined, while "dev" is not defined if the URB it too short.
CVE-2025-13407: The Gravity Forms WordPress plugin before 2.9.23.1 does not properly prevent users from uploading dangerous files through its chunked upload functionality, allowing attackers to upload PHP files to affected sites and achieve Remote Code Execution, granted they can discover or enumerate the upload path.
CVE-2022-50697: In the Linux kernel, the following vulnerability has been resolved:  mrp: introduce active flags to prevent UAF when applicant uninit  The caller of del_timer_sync must prevent restarting of the timer, If we have no this synchronization, there is a small probability that the cancellation will not be successful.  And syzbot report the fellowing crash: ================================================================== BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256 Pointer tag: [f9], memory tag: [fe]  CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace:  dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156  dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline]  show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106  print_address_description mm/kasan/report.c:284 [inline]  print_report+0x1a8/0x4a0 mm/kasan/report.c:395  kasan_report+0x94/0xb4 mm/kasan/report.c:495  __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320  do_bad_area arch/arm64/mm/fault.c:473 [inline]  do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749  do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825  el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367  el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427  el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576  hlist_add_head include/linux/list.h:929 [inline]  enqueue_timer+0x18/0xa4 kernel/time/timer.c:605  mod_timer+0x14/0x20 kernel/time/timer.c:1161  mrp_periodic_timer_arm net/802/mrp.c:614 [inline]  mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627  call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474  expire_timers+0x98/0xc4 kernel/time/timer.c:1519  To fix it, we can introduce a new active flags to make sure the timer will not restart.