xamxte/cve-to-cwe huggingface dataset:
CVE-2025-37834: In the Linux kernel, the following vulnerability has been resolved:  mm/vmscan: don't try to reclaim hwpoison folio  Syzkaller reports a bug as follows:  Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace:  add_to_swap+0xbc/0x158  shrink_folio_list+0x12ac/0x2648  shrink_inactive_list+0x318/0x948  shrink_lruvec+0x450/0x720  shrink_node_memcgs+0x280/0x4a8  shrink_node+0x128/0x978  balance_pgdat+0x4f0/0xb20  kswapd+0x228/0x438  kthread+0x214/0x230  ret_from_fork+0x10/0x20  I can reproduce this issue with the following steps:  1) When a dirty swapcache page is isolated by reclaim process and the    page isn't locked, inject memory failure for the page.     me_swapcache_dirty() clears uptodate flag and tries to delete from lru,    but fails.  Reclaim process will put the hwpoisoned page back to lru.  2) The process that maps the hwpoisoned page exits, the page is deleted    the page will never be freed and will be in the lru forever.  3) If we trigger a reclaim again and tries to reclaim the page,    add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is    cleared.  To fix it, skip the hwpoisoned page in shrink_folio_list().  Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list.
CVE-2025-37836: In the Linux kernel, the following vulnerability has been resolved:  PCI: Fix reference leak in pci_register_host_bridge()  If device_register() fails, call put_device() to give up the reference to avoid a memory leak, per the comment at device_register().  Found by code review.  [bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]
CVE-2025-37856: In the Linux kernel, the following vulnerability has been resolved:  btrfs: harden block_group::bg_list against list_del() races  As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly.  However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry.  Otherwise we risk the following interleaving (bg_list refcount in parens)  T1 (some random op)                       T2 (btrfs_mark_bg_unused)                                         !list_empty(&bg->bg_list); (1) list_del_init(&bg->bg_list); (1)                                         list_move_tail (1) btrfs_put_block_group (0)                                         btrfs_delete_unused_bgs                                              bg = list_first_entry                                              list_del_init(&bg->bg_list);                                              btrfs_put_block_group(bg); (-1)  Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING.
CVE-2025-37871: In the Linux kernel, the following vulnerability has been resolved:  nfsd: decrease sc_count directly if fail to queue dl_recall  A deadlock warning occurred when invoking nfs4_put_stid following a failed dl_recall queue operation:             T1                            T2                                 nfs4_laundromat                                  nfs4_get_client_reaplist                                   nfs4_anylock_blockers __break_lease  spin_lock // ctx->flc_lock                                    spin_lock // clp->cl_lock                                    nfs4_lockowner_has_blockers                                     locks_owner_has_blockers                                      spin_lock // flctx->flc_lock  nfsd_break_deleg_cb   nfsd_break_one_deleg    nfs4_put_stid     refcount_dec_and_lock      spin_lock // clp->cl_lock  When a file is opened, an nfs4_delegation is allocated with sc_count initialized to 1, and the file_lease holds a reference to the delegation. The file_lease is then associated with the file through kernel_setlease.  The disassociation is performed in nfsd4_delegreturn via the following call chain: nfsd4_delegreturn --> destroy_delegation --> destroy_unhashed_deleg --> nfs4_unlock_deleg_lease --> kernel_setlease --> generic_delete_lease The corresponding sc_count reference will be released after this disassociation.  Since nfsd_break_one_deleg executes while holding the flc_lock, the disassociation process becomes blocked when attempting to acquire flc_lock in generic_delete_lease. This means: 1) sc_count in nfsd_break_one_deleg will not be decremented to 0; 2) The nfs4_put_stid called by nfsd_break_one_deleg will not attempt to acquire cl_lock; 3) Consequently, no deadlock condition is created.  Given that sc_count in nfsd_break_one_deleg remains non-zero, we can safely perform refcount_dec on sc_count directly. This approach effectively avoids triggering deadlock warnings.
CVE-2025-3597: The Firelight Lightbox WordPress plugin before 2.3.15 does not prevent users with post writing capabilities from executing arbitrary Javascript when the jQuery Metadata library is enabled. While this feature is meant to only be available to Pro version users, it can be activated in the free version too, making it theoretically exploitable there as well.
CVE-2024-28956: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
CVE-2024-43420: Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution for some Intel Atom(R) processors may allow an authenticated user to potentially enable information disclosure via local access.
CVE-2024-45332: Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution in the indirect branch predictors for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
CVE-2025-20623: Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution for some Intel(R) Core™ processors (10th Generation) may allow an authenticated user to potentially enable information disclosure via local access.
CVE-2025-4664: Insufficient policy enforcement in Loader in Google Chrome prior to 136.0.7103.113 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)
CVE-2023-7231: The illi Link Party! WordPress plugin through 1.0 lacks proper access controls, allowing unauthenticated visitors to delete links.
CVE-2023-7239: The WP Dashboard Notes WordPress plugin before 1.0.11 does not validate that the user has access to the post_id parameter in its wpdn_update_note AJAX action. This allows users with a role of contributor and above to update notes created by other users.
CVE-2024-0970: This User Activity Tracking and Log WordPress plugin before 4.1.4 retrieves client IP addresses from potentially untrusted headers, allowing an attacker to manipulate its value.
CVE-2024-10075: The Jetpack  WordPress plugin before 13.8 does not ensure that the post created by the Contact Form is only accessible to authorised users, which could allow unauthenticated users to run arbitrary shortcodes and block.
CVE-2024-10098: The ApplyOnline  WordPress plugin before 2.6.3 does not protect uploaded files during the application process, allowing unauthenticated users to access them and any private information they contain
CVE-2024-4665: The EventPrime WordPress plugin before 3.5.0 does not properly validate permissions when updating bookings, allowing users to change/cancel bookings for other users. Additionally, the feature is lacking a nonce.
CVE-2024-7762: The Simple Job Board WordPress plugin before 2.12.6 does not prevent uploaded files from being listed, allowing unauthenticated users to access and download uploaded resumes
CVE-2024-8009: The Sensei LMS  WordPress plugin before 4.20.0 disclose all users of the blog including their email address to teachers on the students page
CVE-2024-8673: The Z-Downloads WordPress plugin before 1.11.7 does not properly validate uploaded files allowing for the uploading of SVGs containing malicious JavaScript.
CVE-2024-8699: The Z-Downloads WordPress plugin before 1.11.5 does not properly validate files uploaded, allowing high privilege users such as admin to upload arbitrary files on the server even when they should not be allowed to (for example in multisite setup)
CVE-2024-8700: The Event Calendar WordPress plugin through 1.0.4 does not check for authorization on delete actions, allowing unauthenticated users to delete arbitrary calendars.
CVE-2024-9765: The EKC Tournament Manager WordPress plugin before 2.2.2 allows a logged in admin to download system files outside of the WordPress directory
CVE-2025-4190: The CSV Mass Importer WordPress plugin through 1.2 does not properly validate uploaded files, allowing high privilege users such as admin to upload arbitrary files on the server even when they should not be allowed to (for example in multisite setup)
CVE-2025-37895: In the Linux kernel, the following vulnerability has been resolved:  bnxt_en: Fix error handling path in bnxt_init_chip()  WARN_ON() is triggered in __flush_work() if bnxt_init_chip() fails because we call cancel_work_sync() on dim work that has not been initialized.  WARNING: CPU: 37 PID: 5223 at kernel/workqueue.c:4201 __flush_work.isra.0+0x212/0x230  The driver relies on the BNXT_STATE_NAPI_DISABLED bit to check if dim work has already been cancelled.  But in the bnxt_open() path, BNXT_STATE_NAPI_DISABLED is not set and this causes the error path to think that it needs to cancel the uninitalized dim work. Fix it by setting BNXT_STATE_NAPI_DISABLED during initialization. The bit will be cleared when we enable NAPI and initialize dim work.
CVE-2025-37917: In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll  Use spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock and spin_unlock in mtk_star_emac driver to avoid spinlock recursion occurrence that can happen when enabling the DMA interrupts again in rx/tx poll.  ``` BUG: spinlock recursion on CPU#0, swapper/0/0  lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0,     .owner_cpu: 0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted     6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT Hardware name: MediaTek MT8365 Open Platform EVK (DT) Call trace:  show_stack+0x18/0x24 (C)  dump_stack_lvl+0x60/0x80  dump_stack+0x18/0x24  spin_dump+0x78/0x88  do_raw_spin_lock+0x11c/0x120  _raw_spin_lock+0x20/0x2c  mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac]  __handle_irq_event_percpu+0x48/0x140  handle_irq_event+0x4c/0xb0  handle_fasteoi_irq+0xa0/0x1bc  handle_irq_desc+0x34/0x58  generic_handle_domain_irq+0x1c/0x28  gic_handle_irq+0x4c/0x120  do_interrupt_handler+0x50/0x84  el1_interrupt+0x34/0x68  el1h_64_irq_handler+0x18/0x24  el1h_64_irq+0x6c/0x70  regmap_mmio_read32le+0xc/0x20 (P)  _regmap_bus_reg_read+0x6c/0xac  _regmap_read+0x60/0xdc  regmap_read+0x4c/0x80  mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac]  __napi_poll+0x38/0x188  net_rx_action+0x164/0x2c0  handle_softirqs+0x100/0x244  __do_softirq+0x14/0x20  ____do_softirq+0x10/0x20  call_on_irq_stack+0x24/0x64  do_softirq_own_stack+0x1c/0x40  __irq_exit_rcu+0xd4/0x10c  irq_exit_rcu+0x10/0x1c  el1_interrupt+0x38/0x68  el1h_64_irq_handler+0x18/0x24  el1h_64_irq+0x6c/0x70  cpuidle_enter_state+0xac/0x320 (P)  cpuidle_enter+0x38/0x50  do_idle+0x1e4/0x260  cpu_startup_entry+0x34/0x3c  rest_init+0xdc/0xe0  console_on_rootfs+0x0/0x6c  __primary_switched+0x88/0x90 ```
CVE-2025-37921: In the Linux kernel, the following vulnerability has been resolved:  vxlan: vnifilter: Fix unlocked deletion of default FDB entry  When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").  Reproducer:   # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1  # bridge vni add vni 10010 remote 198.51.100.1 dev vx0  # bridge vni del vni 10010 dev vx0  Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it.  [1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Call Trace:  <TASK>  __vxlan_fdb_delete+0xbe/0x560  vxlan_vni_delete_group+0x2ba/0x940  vxlan_vni_del.isra.0+0x15f/0x580  vxlan_process_vni_filter+0x38b/0x7b0  vxlan_vnifilter_process+0x3bb/0x510  rtnetlink_rcv_msg+0x2f7/0xb70  netlink_rcv_skb+0x131/0x360  netlink_unicast+0x426/0x710  netlink_sendmsg+0x75a/0xc20  __sock_sendmsg+0xc1/0x150  ____sys_sendmsg+0x5aa/0x7b0  ___sys_sendmsg+0xfc/0x180  __sys_sendmsg+0x121/0x1b0  do_syscall_64+0xbb/0x1d0  entry_SYSCALL_64_after_hwframe+0x4b/0x53
CVE-2025-37931: In the Linux kernel, the following vulnerability has been resolved:  btrfs: adjust subpage bit start based on sectorsize  When running machines with 64k page size and a 16k nodesize we started seeing tree log corruption in production.  This turned out to be because we were not writing out dirty blocks sometimes, so this in fact affects all metadata writes.  When writing out a subpage EB we scan the subpage bitmap for a dirty range.  If the range isn't dirty we do   bit_start++;  to move onto the next bit.  The problem is the bitmap is based on the number of sectors that an EB has.  So in this case, we have a 64k pagesize, 16k nodesize, but a 4k sectorsize.  This means our bitmap is 4 bits for every node.  With a 64k page size we end up with 4 nodes per page.  To make this easier this is how everything looks  [0         16k       32k       48k     ] logical address [0         4         8         12      ] radix tree offset [               64k page               ] folio [ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers [ | | | |  | | | |   | | | |   | | | | ] bitmap  Now we use all of our addressing based on fs_info->sectorsize_bits, so as you can see the above our 16k eb->start turns into radix entry 4.  When we find a dirty range for our eb, we correctly do bit_start += sectors_per_node, because if we start at bit 0, the next bit for the next eb is 4, to correspond to eb->start 16k.  However if our range is clean, we will do bit_start++, which will now put us offset from our radix tree entries.  In our case, assume that the first time we check the bitmap the block is not dirty, we increment bit_start so now it == 1, and then we loop around and check again.  This time it is dirty, and we go to find that start using the following equation   start = folio_start + bit_start * fs_info->sectorsize;  so in the case above, eb->start 0 is now dirty, and we calculate start as   0 + 1 * fs_info->sectorsize = 4096  4096 >> 12 = 1  Now we're looking up the radix tree for 1, and we won't find an eb. What's worse is now we're using bit_start == 1, so we do bit_start += sectors_per_node, which is now 5.  If that eb is dirty we will run into the same thing, we will look at an offset that is not populated in the radix tree, and now we're skipping the writeout of dirty extent buffers.  The best fix for this is to not use sectorsize_bits to address nodes, but that's a larger change.  Since this is a fs corruption problem fix it simply by always using sectors_per_node to increment the start bit.
CVE-2025-37954: In the Linux kernel, the following vulnerability has been resolved:  smb: client: Avoid race in open_cached_dir with lease breaks  A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs.  Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked.
CVE-2025-37964: In the Linux kernel, the following vulnerability has been resolved:  x86/mm: Eliminate window where TLB flushes may be inadvertently skipped  tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm.  But should_flush_tlb() has a bug and suppresses the flush.  Fix it by widening the window where should_flush_tlb() sends an IPI.  Long Version:  === History ===  There were a few things leading up to this.  First, updating mm_cpumask() was observed to be too expensive, so it was made lazier.  But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask().  So code was added to cull mm_cpumask() periodically[2].  But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them.  So here we are again.  === Problem ===  The too-aggressive code in should_flush_tlb() strikes in this window:   // Turn on IPIs for this CPU/mm combination, but only  // if should_flush_tlb() agrees:  cpumask_set_cpu(cpu, mm_cpumask(next));   next_tlb_gen = atomic64_read(&next->context.tlb_gen);  choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush);  load_new_mm_cr3(need_flush);  // ^ After 'need_flush' is set to false, IPIs *MUST*  // be sent to this CPU and not be ignored.          this_cpu_write(cpu_tlbstate.loaded_mm, next);  // ^ Not until this point does should_flush_tlb()  // become true!  should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed.  Whoops.  === Solution ===  Thankfully, the fuzzy "just about to write CR3" window is already marked with loaded_mm==LOADED_MM_SWITCHING.  Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI.  This will cause more TLB flush IPIs.  But the window is relatively small and I do not expect this to cause any kind of measurable performance impact.  Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user.  Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them.  Add a barrier to ensure that they are observed in the order they are written.
CVE-2025-37986: In the Linux kernel, the following vulnerability has been resolved:  usb: typec: class: Invalidate USB device pointers on partner unregistration  To avoid using invalid USB device pointers after a Type-C partner disconnects, this patch clears the pointers upon partner unregistration. This ensures a clean state for future connections.
CVE-2025-37987: In the Linux kernel, the following vulnerability has been resolved:  pds_core: Prevent possible adminq overflow/stuck condition  The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion.  On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW.  As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16.
CVE-2025-4094: The DIGITS: WordPress Mobile Number Signup and Login WordPress plugin before 8.4.6.1 does not rate limit OTP validation attempts, making it straightforward for attackers to bruteforce them.
CVE-2025-37993: In the Linux kernel, the following vulnerability has been resolved:  can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probe  The spin lock tx_handling_spinlock in struct m_can_classdev is not being initialized. This leads the following spinlock bad magic complaint from the kernel, eg. when trying to send CAN frames with cansend from can-utils:  | BUG: spinlock bad magic on CPU#0, cansend/95 |  lock: 0xff60000002ec1010, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 | CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE | Hardware name: MachineWare SIM-V (DT) | Call Trace: | [<ffffffff800133e0>] dump_backtrace+0x1c/0x24 | [<ffffffff800022f2>] show_stack+0x28/0x34 | [<ffffffff8000de3e>] dump_stack_lvl+0x4a/0x68 | [<ffffffff8000de70>] dump_stack+0x14/0x1c | [<ffffffff80003134>] spin_dump+0x62/0x6e | [<ffffffff800883ba>] do_raw_spin_lock+0xd0/0x142 | [<ffffffff807a6fcc>] _raw_spin_lock_irqsave+0x20/0x2c | [<ffffffff80536dba>] m_can_start_xmit+0x90/0x34a | [<ffffffff806148b0>] dev_hard_start_xmit+0xa6/0xee | [<ffffffff8065b730>] sch_direct_xmit+0x114/0x292 | [<ffffffff80614e2a>] __dev_queue_xmit+0x3b0/0xaa8 | [<ffffffff8073b8fa>] can_send+0xc6/0x242 | [<ffffffff8073d1c0>] raw_sendmsg+0x1a8/0x36c | [<ffffffff805ebf06>] sock_write_iter+0x9a/0xee | [<ffffffff801d06ea>] vfs_write+0x184/0x3a6 | [<ffffffff801d0a88>] ksys_write+0xa0/0xc0 | [<ffffffff801d0abc>] __riscv_sys_write+0x14/0x1c | [<ffffffff8079ebf8>] do_trap_ecall_u+0x168/0x212 | [<ffffffff807a830a>] handle_exception+0x146/0x152  Initializing the spin lock in m_can_class_allocate_dev solves that problem.