xamxte/cve-to-cwe huggingface dataset:
CVE-2023-53853: In the Linux kernel, the following vulnerability has been resolved:  netlink: annotate accesses to nlk->cb_running  Both netlink_recvmsg() and netlink_native_seq_show() read nlk->cb_running locklessly. Use READ_ONCE() there.  Add corresponding WRITE_ONCE() to netlink_dump() and __netlink_dump_start()  syzbot reported: BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsg  write to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0: __netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399 netlink_dump_start include/linux/netlink.h:308 [inline] rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] sock_write_iter+0x1aa/0x230 net/socket.c:1138 call_write_iter include/linux/fs.h:1851 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x463/0x760 fs/read_write.c:584 ksys_write+0xeb/0x1a0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x42/0x50 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  read to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1: netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022 sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017 ____sys_recvmsg+0x2db/0x310 net/socket.c:2718 ___sys_recvmsg net/socket.c:2762 [inline] do_recvmmsg+0x2e5/0x710 net/socket.c:2856 __sys_recvmmsg net/socket.c:2935 [inline] __do_sys_recvmmsg net/socket.c:2958 [inline] __se_sys_recvmmsg net/socket.c:2951 [inline] __x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  value changed: 0x00 -> 0x01
CVE-2023-53854: In the Linux kernel, the following vulnerability has been resolved:  ASoC: mediatek: mt8186: Fix use-after-free in driver remove path  When devm runs function in the "remove" path for a device it runs them in the reverse order. That means that if you have parts of your driver that aren't using devm or are using "roll your own" devm w/ devm_add_action_or_reset() you need to keep that in mind.  The mt8186 audio driver didn't quite get this right. Specifically, in mt8186_init_clock() it called mt8186_audsys_clk_register() and then went on to call a bunch of other devm function. The caller of mt8186_init_clock() used devm_add_action_or_reset() to call mt8186_deinit_clock() but, because of the intervening devm functions, the order was wrong.  Specifically at probe time, the order was: 1. mt8186_audsys_clk_register() 2. afe_priv->clk = devm_kcalloc(...) 3. afe_priv->clk[i] = devm_clk_get(...)  At remove time, the order (which should have been 3, 2, 1) was: 1. mt8186_audsys_clk_unregister() 3. Free all of afe_priv->clk[i] 2. Free afe_priv->clk  The above seemed to be causing a use-after-free. Luckily, it's easy to fix this by simply using devm more correctly. Let's move the devm_add_action_or_reset() to the right place. In addition to fixing the use-after-free, code inspection shows that this fixes a leak (missing call to mt8186_audsys_clk_unregister()) that would have happened if any of the syscon_regmap_lookup_by_phandle() calls in mt8186_init_clock() had failed.
CVE-2023-53856: In the Linux kernel, the following vulnerability has been resolved:  of: overlay: Call of_changeset_init() early  When of_overlay_fdt_apply() fails, the changeset may be partially applied, and the caller is still expected to call of_overlay_remove() to clean up this partial state.  However, of_overlay_apply() calls of_resolve_phandles() before init_overlay_changeset().  Hence if the overlay fails to apply due to an unresolved symbol, the overlay_changeset.cset.entries list is still uninitialized, and cleanup will crash with a NULL-pointer dereference in overlay_removal_is_ok().  Fix this by moving the call to of_changeset_init() from init_overlay_changeset() to of_overlay_fdt_apply(), where all other early initialization is done.
CVE-2023-53858: In the Linux kernel, the following vulnerability has been resolved:  tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of error  If clk_get_rate() fails, the clk that has just been allocated needs to be freed.
CVE-2023-53861: In the Linux kernel, the following vulnerability has been resolved:  ext4: correct grp validation in ext4_mb_good_group  Group corruption check will access memory of grp and will trigger kernel crash if grp is NULL. So do NULL check before corruption check.
CVE-2023-53864: In the Linux kernel, the following vulnerability has been resolved:  drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()  When disabling overlay plane in mxsfb_plane_overlay_atomic_update(), overlay plane's framebuffer pointer is NULL.  So, dereferencing it would cause a kernel Oops(NULL pointer dereferencing).  Fix the issue by disabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead.
CVE-2023-53866: In the Linux kernel, the following vulnerability has been resolved:  ASoC: soc-compress: Reposition and add pcm_mutex  If panic_on_warn is set and compress stream(DPCM) is started, then kernel panic occurred because card->pcm_mutex isn't held appropriately. In the following functions, warning were issued at this line "snd_soc_dpcm_mutex_assert_held".  static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe,   struct snd_soc_pcm_runtime *be, int stream) {  ...  snd_soc_dpcm_mutex_assert_held(fe);  ... }  void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream) {  ...  snd_soc_dpcm_mutex_assert_held(fe);  ... }  void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd,        int stream, int action) {  ...  snd_soc_dpcm_mutex_assert_held(rtd);  ... }  int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir,  int event) {  ...  snd_soc_dpcm_mutex_assert_held(fe);  ... }  These functions are called by soc_compr_set_params_fe, soc_compr_open_fe and soc_compr_free_fe without pcm_mutex locking. And this is call stack.  [  414.527841][ T2179] pc : dpcm_process_paths+0x5a4/0x750 [  414.527848][ T2179] lr : dpcm_process_paths+0x37c/0x750 [  414.527945][ T2179] Call trace: [  414.527949][ T2179]  dpcm_process_paths+0x5a4/0x750 [  414.527955][ T2179]  soc_compr_open_fe+0xb0/0x2cc [  414.527972][ T2179]  snd_compr_open+0x180/0x248 [  414.527981][ T2179]  snd_open+0x15c/0x194 [  414.528003][ T2179]  chrdev_open+0x1b0/0x220 [  414.528023][ T2179]  do_dentry_open+0x30c/0x594 [  414.528045][ T2179]  vfs_open+0x34/0x44 [  414.528053][ T2179]  path_openat+0x914/0xb08 [  414.528062][ T2179]  do_filp_open+0xc0/0x170 [  414.528068][ T2179]  do_sys_openat2+0x94/0x18c [  414.528076][ T2179]  __arm64_sys_openat+0x78/0xa4 [  414.528084][ T2179]  invoke_syscall+0x48/0x10c [  414.528094][ T2179]  el0_svc_common+0xbc/0x104 [  414.528099][ T2179]  do_el0_svc+0x34/0xd8 [  414.528103][ T2179]  el0_svc+0x34/0xc4 [  414.528125][ T2179]  el0t_64_sync_handler+0x8c/0xfc [  414.528133][ T2179]  el0t_64_sync+0x1a0/0x1a4 [  414.528142][ T2179] Kernel panic - not syncing: panic_on_warn set ...  So, I reposition and add pcm_mutex to resolve lockdep error.
CVE-2025-13031: The WPeMatico RSS Feed Fetcher WordPress plugin before 2.8.13 does not sanitize and escape some of its settings, which could allow high privilege users such as contributor to perform Stored Cross-Site Scripting attacks
CVE-2025-40327: In the Linux kernel, the following vulnerability has been resolved:  perf/core: Fix system hang caused by cpu-clock usage  cpu-clock usage by the async-profiler tool can trigger a system hang, which got bisected back to the following commit by Octavia Togami:    18dbcbfabfff ("perf: Fix the POLL_HUP delivery breakage") causes this issue  The root cause of the hang is that cpu-clock is a special type of SW event which relies on hrtimers. The __perf_event_overflow() callback is invoked from the hrtimer handler for cpu-clock events, and __perf_event_overflow() tries to call cpu_clock_event_stop() to stop the event, which calls htimer_cancel() to cancel the hrtimer.  But that's a recursion into the hrtimer code from a hrtimer handler, which (unsurprisingly) deadlocks.  To fix this bug, use hrtimer_try_to_cancel() instead, and set the PERF_HES_STOPPED flag, which causes perf_swevent_hrtimer() to stop the event once it sees the PERF_HES_STOPPED flag.  [ mingo: Fixed the comments and improved the changelog. ]
CVE-2025-40328: In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix potential UAF in smb2_close_cached_fid()  find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free.  Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.
CVE-2025-40329: In the Linux kernel, the following vulnerability has been resolved:  drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb  The Mesa issue referenced below pointed out a possible deadlock:  [ 1231.611031]  Possible interrupt unsafe locking scenario:  [ 1231.611033]        CPU0                    CPU1 [ 1231.611034]        ----                    ---- [ 1231.611035]   lock(&xa->xa_lock#17); [ 1231.611038]                                local_irq_disable(); [ 1231.611039]                                lock(&fence->lock); [ 1231.611041]                                lock(&xa->xa_lock#17); [ 1231.611044]   <Interrupt> [ 1231.611045]     lock(&fence->lock); [ 1231.611047]                 *** DEADLOCK ***  In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).  CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0.  Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback.    dma_fence_signal() // locks f1.lock   -> drm_sched_entity_kill_jobs_cb()   -> foreach dependencies      -> dma_fence_add_callback() // locks f2.lock  This will deadlock if f1 and f2 share the same spinlock.  To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work().  [phasta: commit message nits]
CVE-2025-40331: In the Linux kernel, the following vulnerability has been resolved:  sctp: Prevent TOCTOU out-of-bounds write  For the following path not holding the sock lock,    sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()  make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use).
CVE-2025-40332: In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Fix mmap write lock not release  If mmap write lock is taken while draining retry fault, mmap write lock is not released because svm_range_restore_pages calls mmap_read_unlock then returns. This causes deadlock and system hangs later because mmap read or write lock cannot be taken.  Downgrade mmap write lock to read lock if draining retry fault fix this bug.
CVE-2025-40333: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix infinite loop in __insert_extent_tree()  When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case.
CVE-2025-40335: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: validate userq input args  This will help on validating the userq input args, and rejecting for the invalid userq request at the IOCTLs first place.
CVE-2025-40338: In the Linux kernel, the following vulnerability has been resolved:  ASoC: Intel: avs: Do not share the name pointer between components  By sharing 'name' directly, tearing down components may lead to use-after-free errors. Duplicate the name to avoid that.  At the same time, update the order of operations - since commit cee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name via config") the framework does not override component->name if set before invoking the initializer.
CVE-2025-40339: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix nullptr err of vm_handle_moved  If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved.
CVE-2025-40340: In the Linux kernel, the following vulnerability has been resolved:  drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test.  I saw an oops in xe_gem_fault when running the xe-fast-feedback testlist against the realtime kernel without debug options enabled.  The panic happens after core_hotunplug unbind-rebind finishes. Presumably what happens is that a process mmaps, unlocks because of the FAULT_FLAG_RETRY_NOWAIT logic, has no process memory left, causing ttm_bo_vm_dummy_page() to return VM_FAULT_NOPAGE, since there was nothing left to populate, and then oopses in "mem_type_is_vram(tbo->resource->mem_type)" because tbo->resource is NULL.  It's convoluted, but fits the data and explains the oops after the test exits.
CVE-2025-40341: In the Linux kernel, the following vulnerability has been resolved:  futex: Don't leak robust_list pointer on exec race  sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process.  During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged.  A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec().  For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process.  This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk.  Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.
CVE-2025-40342: In the Linux kernel, the following vulnerability has been resolved:  nvme-fc: use lock accessing port_state and rport state  nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.
CVE-2025-40343: In the Linux kernel, the following vulnerability has been resolved:  nvmet-fc: avoid scheduling association deletion twice  When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion.  The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion.  Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.
CVE-2025-40344: In the Linux kernel, the following vulnerability has been resolved:  ASoC: Intel: avs: Disable periods-elapsed work when closing PCM  avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors.
CVE-2025-13072: The HandL UTM Grabber / Tracker WordPress plugin before 2.8.1 does not sanitize 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-13073: The HandL UTM Grabber / Tracker WordPress plugin before 2.8.1 does not sanitize 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-55183: An information leak vulnerability exists in specific configurations of React Server Components versions 19.0.0, 19.0.1 19.1.0, 19.1.1, 19.1.2, 19.2.0 and 19.2.1, including the following packages: react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack. A specifically crafted HTTP request sent to a vulnerable Server Function may unsafely return the source code of any Server Function. Exploitation requires the existence of a Server Function which explicitly or implicitly exposes a stringified argument.
CVE-2025-12835: The WooMulti WordPress plugin through 17 does not validate a file parameter when deleting files, which could allow any authenticated users, such as subscriber to delete arbitrary files on the server.
CVE-2025-12841: The Bookit WordPress plugin before 2.5.1 has a publicly accessible REST endpoint that allows unauthenticated update of the plugins Stripe payment options.
CVE-2025-36743: SolarEdge SE3680H has an exposed debug/test interface accessible to unauthenticated actors, allowing disclosure of system internals and execution of debug commands.
CVE-2025-36744: SolarEdge SE3680H has unauthenticated disclosure of sensitive information during the bootloader loop. While the device repeatedly initializes and waits for boot instructions, the bootloader emits diagnostic output this behavior can leak operating system information.
CVE-2025-40345: In the Linux kernel, the following vulnerability has been resolved:  usb: storage: sddr55: Reject out-of-bound new_pba  Discovered by Atuin - Automated Vulnerability Discovery Engine.  new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory.  Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.
CVE-2025-46276: An information disclosure issue was addressed with improved privacy controls. This issue is fixed in watchOS 26.2, macOS Sonoma 14.8.3, iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Tahoe 26.2, macOS Sequoia 15.7.3, visionOS 26.2. An app may be able to access sensitive user data.
CVE-2025-9116: The WPS Visitor Counter Plugin WordPress plugin through 1.4.8 does not escape the $_SERVER['REQUEST_URI'] parameter before outputting it back in an attribute, which could lead to Reflected Cross-Site Scripting in old web browsers.
CVE-2025-12696: The HelloLeads CRM Form Shortcode WordPress plugin through 1.0 does not have authorisation and CSRF check when resetting its settings, allowing unauthenticated users to reset them
CVE-2025-11363: The Royal Addons for Elementor  WordPress plugin before 1.7.1037 does not have proper authorisation, allowing unauthenticated users to upload media files via the wpr_addons_upload_file action.
CVE-2025-12684: The URL Shortify  WordPress plugin before 1.11.3 does not sanitize 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 admins.
CVE-2025-13355: The URL Shortify  WordPress plugin before 1.11.4 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-40346: In the Linux kernel, the following vulnerability has been resolved:  arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()  Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().  Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise."  This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.  Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().
CVE-2025-40347: In the Linux kernel, the following vulnerability has been resolved:  net: enetc: fix the deadlock of enetc_mdio_lock  After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock:  enetc_poll   -> enetc_lock_mdio   -> enetc_clean_rx_ring OR napi_complete_done      -> napi_gro_receive         -> enetc_start_xmit            -> enetc_lock_mdio            -> enetc_map_tx_buffs            -> enetc_unlock_mdio   -> enetc_unlock_mdio  After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang.  Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition.
CVE-2025-40348: In the Linux kernel, the following vulnerability has been resolved:  slab: Avoid race on slab->obj_exts in alloc_slab_obj_exts  If two competing threads enter alloc_slab_obj_exts() and one of them fails to allocate the object extension vector, it might override the valid slab->obj_exts allocated by the other thread with OBJEXTS_ALLOC_FAIL. This will cause the thread that lost this race and expects a valid pointer to dereference a NULL pointer later on.  Update slab->obj_exts atomically using cmpxchg() to avoid slab->obj_exts overrides by racing threads.  Thanks for Vlastimil and Suren's help with debugging.