xamxte/cve-to-cwe huggingface dataset:
CVE-2023-54307: In the Linux kernel, the following vulnerability has been resolved:  ptp_qoriq: fix memory leak in probe()  Smatch complains that: drivers/ptp/ptp_qoriq.c ptp_qoriq_probe() warn: 'base' from ioremap() not released.  Fix this by revising the parameter from 'ptp_qoriq->base' to 'base'. This is only a bug if ptp_qoriq_init() returns on the first -ENODEV error path. For other error paths ptp_qoriq->base and base are the same. And this change makes the code more readable.
CVE-2023-54309: In the Linux kernel, the following vulnerability has been resolved:  tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation  /dev/vtpmx is made visible before 'workqueue' is initialized, which can lead to a memory corruption in the worst case scenario.  Address this by initializing 'workqueue' as the very first step of the driver initialization.
CVE-2023-54310: In the Linux kernel, the following vulnerability has been resolved:  scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race condition  mptlan_probe() calls mpt_register_lan_device() which initializes the &priv->post_buckets_task workqueue. A call to mpt_lan_wake_post_buckets_task() will subsequently start the work.  During driver unload in mptlan_remove() the following race may occur:  CPU0                  CPU1                      |mpt_lan_post_receive_buckets_work() mptlan_remove()     |   free_netdev()     |     kfree(dev);     |                     |                     | dev->mtu                     |   //use  Fix this by finishing the work prior to cleaning up in mptlan_remove().  [mkp: we really should remove mptlan instead of attempting to fix it]
CVE-2023-54311: In the Linux kernel, the following vulnerability has been resolved:  ext4: fix deadlock when converting an inline directory in nojournal mode  In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock by calling ext4_handle_dirty_dirblock() when it already has taken the directory lock.  There is a similar self-deadlock in ext4_incvert_inline_data_nolock() for data files which we'll fix at the same time.  A simple reproducer demonstrating the problem:      mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64     mount -t ext4 -o dirsync /dev/vdc /vdc     cd /vdc     mkdir file0     cd file0     touch file0     touch file1     attr -s BurnSpaceInEA -V abcde .     touch supercalifragilisticexpialidocious
CVE-2023-54312: In the Linux kernel, the following vulnerability has been resolved:  samples/bpf: Fix buffer overflow in tcp_basertt  Using sizeof(nv) or strlen(nv)+1 is correct.
CVE-2023-54313: In the Linux kernel, the following vulnerability has been resolved:  ovl: fix null pointer dereference in ovl_get_acl_rcu()  Following process:          P1                     P2  path_openat   link_path_walk    may_lookup     inode_permission(rcu)      ovl_permission       acl_permission_check        check_acl         get_cached_acl_rcu   ovl_get_inode_acl    realinode = ovl_inode_real(ovl_inode)                        drop_cache                  __dentry_kill(ovl_dentry)     iput(ovl_inode)                    ovl_destroy_inode(ovl_inode)                     dput(oi->__upperdentry)                      dentry_kill(upperdentry)                       dentry_unlink_inode          upperdentry->d_inode = NULL      ovl_inode_upper       upperdentry = ovl_i_dentry_upper(ovl_inode)       d_inode(upperdentry) // returns NULL    IS_POSIXACL(realinode) // NULL pointer dereference , will trigger an null pointer dereference at realinode:   [  205.472797] BUG: kernel NULL pointer dereference, address:                  0000000000000028   [  205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted                  6.3.0-12064-g2edfa098e750-dirty #1216   [  205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300   [  205.489584] Call Trace:   [  205.489812]  <TASK>   [  205.490014]  ovl_get_inode_acl+0x26/0x30   [  205.490466]  get_cached_acl_rcu+0x61/0xa0   [  205.490908]  generic_permission+0x1bf/0x4e0   [  205.491447]  ovl_permission+0x79/0x1b0   [  205.491917]  inode_permission+0x15e/0x2c0   [  205.492425]  link_path_walk+0x115/0x550   [  205.493311]  path_lookupat.isra.0+0xb2/0x200   [  205.493803]  filename_lookup+0xda/0x240   [  205.495747]  vfs_fstatat+0x7b/0xb0  Fetch a reproducer in [Link].  Use the helper ovl_i_path_realinode() to get realinode and then do non-nullptr checking.
CVE-2023-54314: In the Linux kernel, the following vulnerability has been resolved:  media: af9005: Fix null-ptr-deref in af9005_i2c_xfer  In af9005_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9005_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.  Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
CVE-2023-54315: In the Linux kernel, the following vulnerability has been resolved:  powerpc/powernv/sriov: perform null check on iov before dereferencing iov  Currently pointer iov is being dereferenced before the null check of iov which can lead to null pointer dereference errors. Fix this by moving the iov null check before the dereferencing.  Detected using cppcheck static analysis: linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either the condition '!iov' is redundant or there is possible null pointer dereference: iov. [nullPointerRedundantCheck]  num_vfs = iov->num_vfs;            ^
CVE-2023-54316: In the Linux kernel, the following vulnerability has been resolved:  refscale: Fix uninitalized use of wait_queue_head_t  Running the refscale test occasionally crashes the kernel with the following error:  [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 8569.952900] #PF: supervisor read access in kernel mode [ 8569.952902] #PF: error_code(0x0000) - not-present page [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0 [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021 [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190   : [ 8569.952940] Call Trace: [ 8569.952941]  <TASK> [ 8569.952944]  ref_scale_reader+0x380/0x4a0 [refscale] [ 8569.952959]  kthread+0x10e/0x130 [ 8569.952966]  ret_from_fork+0x1f/0x30 [ 8569.952973]  </TASK>  The likely cause is that init_waitqueue_head() is called after the call to the torture_create_kthread() function that creates the ref_scale_reader kthread.  Although this init_waitqueue_head() call will very likely complete before this kthread is created and starts running, it is possible that the calling kthread will be delayed between the calls to torture_create_kthread() and init_waitqueue_head().  In this case, the new kthread will use the waitqueue head before it is properly initialized, which is not good for the kernel's health and well-being.  The above crash happened here:   static inline void __add_wait_queue(...)  {   :   if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here  The offset of flags from list_head entry in wait_queue_entry is -0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task structure is zero initialized, the instruction will try to access address 0xffffffffffffffe8, which is exactly the fault address listed above.  This commit therefore invokes init_waitqueue_head() before creating the kthread.
CVE-2023-54317: In the Linux kernel, the following vulnerability has been resolved:  dm flakey: don't corrupt the zero page  When we need to zero some range on a block device, the function __blkdev_issue_zero_pages submits a write bio with the bio vector pointing to the zero page. If we use dm-flakey with corrupt bio writes option, it will corrupt the content of the zero page which results in crashes of various userspace programs. Glibc assumes that memory returned by mmap is zeroed and it uses it for calloc implementation; if the newly mapped memory is not zeroed, calloc will return non-zeroed memory.  Fix this bug by testing if the page is equal to ZERO_PAGE(0) and avoiding the corruption in this case.
CVE-2023-54318: In the Linux kernel, the following vulnerability has been resolved:  net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add  While doing smcr_port_add, there maybe linkgroup add into or delete from smc_lgr_list.list at the same time, which may result kernel crash. So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add.  The crash calltrace show below: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014 Workqueue: events smc_ib_port_event_work [smc] RIP: 0010:smcr_port_add+0xa6/0xf0 [smc] RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918 R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4 R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08 FS:  0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0 PKRU: 55555554 Call Trace:  smc_ib_port_event_work+0x18f/0x380 [smc]  process_one_work+0x19b/0x340  worker_thread+0x30/0x370  ? process_one_work+0x340/0x340  kthread+0x114/0x130  ? __kthread_cancel_work+0x50/0x50  ret_from_fork+0x1f/0x30
CVE-2023-54319: In the Linux kernel, the following vulnerability has been resolved:  pinctrl: at91-pio4: check return value of devm_kasprintf()  devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script).  Depends-on: 1c4e5c470a56 ("pinctrl: at91: use devm_kasprintf() to avoid potential leaks") Depends-on: 5a8f9cf269e8 ("pinctrl: at91-pio4: use proper format specifier for unsigned int")
CVE-2023-54320: In the Linux kernel, the following vulnerability has been resolved:  platform/x86/amd: pmc: Fix memory leak in amd_pmc_stb_debugfs_open_v2()  Function amd_pmc_stb_debugfs_open_v2() may be called when the STB debug mechanism enabled.  When amd_pmc_send_cmd() fails, the 'buf' needs to be released.
CVE-2023-54323: In the Linux kernel, the following vulnerability has been resolved:  cxl/pmem: Fix nvdimm registration races  A loop of the form:      while true; do modprobe cxl_pci; modprobe -r cxl_pci; done  ...fails with the following crash signature:      BUG: kernel NULL pointer dereference, address: 0000000000000040     [..]     RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core]     [..]     Call Trace:      <TASK>      cxl_pmem_ctl+0x121/0x240 [cxl_pmem]      nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm]      nd_label_data_init+0x135/0x7e0 [libnvdimm]      nvdimm_probe+0xd6/0x1c0 [libnvdimm]      nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm]      really_probe+0xde/0x380      __driver_probe_device+0x78/0x170      driver_probe_device+0x1f/0x90      __device_attach_driver+0x85/0x110      bus_for_each_drv+0x7d/0xc0      __device_attach+0xb4/0x1e0      bus_probe_device+0x9f/0xc0      device_add+0x445/0x9c0      nd_async_device_register+0xe/0x40 [libnvdimm]      async_run_entry_fn+0x30/0x130  ...namely that the bottom half of async nvdimm device registration runs after the CXL has already torn down the context that cxl_pmem_ctl() needs. Unlike the ACPI NFIT case that benefits from launching multiple nvdimm device registrations in parallel from those listed in the table, CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for a synchronous registration path to preclude this scenario.
CVE-2023-54324: In the Linux kernel, the following vulnerability has been resolved:  dm: fix a race condition in retrieve_deps  There's a race condition in the multipath target when retrieve_deps races with multipath_message calling dm_get_device and dm_put_device. retrieve_deps walks the list of open devices without holding any lock but multipath may add or remove devices to the list while it is running. The end result may be memory corruption or use-after-free memory access.  See this description of a UAF with multipath_message(): https://listman.redhat.com/archives/dm-devel/2022-October/052373.html  Fix this bug by introducing a new rw semaphore "devices_lock". We grab devices_lock for read in retrieve_deps and we grab it for write in dm_get_device and dm_put_device.
CVE-2023-54325: In the Linux kernel, the following vulnerability has been resolved:  crypto: qat - fix out-of-bounds read  When preparing an AER-CTR request, the driver copies the key provided by the user into a data structure that is accessible by the firmware. If the target device is QAT GEN4, the key size is rounded up by 16 since a rounded up size is expected by the device. If the key size is rounded up before the copy, the size used for copying the key might be bigger than the size of the region containing the key, causing an out-of-bounds read.  Fix by doing the copy first and then update the keylen.  This is to fix the following warning reported by KASAN:   [  138.150574] BUG: KASAN: global-out-of-bounds in qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat]  [  138.150641] Read of size 32 at addr ffffffff88c402c0 by task cryptomgr_test/2340   [  138.150651] CPU: 15 PID: 2340 Comm: cryptomgr_test Not tainted 6.2.0-rc1+ #45  [  138.150659] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.86B.0087.D13.2208261706 08/26/2022  [  138.150663] Call Trace:  [  138.150668]  <TASK>  [  138.150922]  kasan_check_range+0x13a/0x1c0  [  138.150931]  memcpy+0x1f/0x60  [  138.150940]  qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat]  [  138.151006]  qat_alg_skcipher_init_sessions+0xc1/0x240 [intel_qat]  [  138.151073]  crypto_skcipher_setkey+0x82/0x160  [  138.151085]  ? prepare_keybuf+0xa2/0xd0  [  138.151095]  test_skcipher_vec_cfg+0x2b8/0x800
CVE-2025-15111: Ksenia Security lares (legacy model) version 1.6 contains a default credentials vulnerability that allows unauthorized attackers to gain administrative access. Attackers can exploit the weak default administrative credentials to obtain full control of the home automation system.
CVE-2025-15112: Ksenia Security lares (legacy model) version 1.6 contains a URL redirection vulnerability in the 'cmdOk.xml' script that allows attackers to manipulate the 'redirectPage' GET parameter. Attackers can craft malicious links that redirect authenticated users to arbitrary websites when clicking on a specially constructed link hosted on a trusted domain.
CVE-2025-13029: The Knowband Mobile App Builder WordPress plugin before 3.0.0 does not have authorisation when deleting users via its REST API, allowing unauthenticated attackers to delete arbitrary users.
CVE-2025-14434: The Ultimate Post Kit Addons for Elementor WordPress plugin before 4.0.16 exposes multiple AJAX “load more” endpoints such as upk_alex_grid_loadmore_posts without ensuring that posts to be displayed are published authentication. This allows an unauthenticated attacker to query arbitrary posts and retrieve rendered HTML content of private and unpublished ones.
CVE-2025-13820: The Comments  WordPress plugin before 7.6.40 does not properly validate user's identity when using the disqus.com provider, allowing an attacker to log in to any user (when knowing their email address) when such user does not have an account on disqus.com yet.
CVE-2025-12685: The WPBookit WordPress plugin through 1.0.7 lacks a CSRF check when deleting customers. This could allow an unauthenticated attacker to delete any customer through a CSRF attack.
CVE-2025-13153: The Logo Slider  WordPress plugin before 4.9.0 does not validate and escape some of its slider options before outputting them back in the dashboard, which could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks.
CVE-2025-13456: The ShopBuilder  WordPress plugin before 3.2.2 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-14072: The Ninja Forms  WordPress plugin before 3.13.3 allows unauthenticated attackers to generate valid access tokens via the REST API which can then be used to read form submissions.
CVE-2025-14124: The Team  WordPress plugin before 5.0.11 does not properly sanitize and escape a parameter before using it in a SQL statement via an AJAX action available to unauthenticated users, leading to a SQL injection.
CVE-2025-9543: The FlexTable  WordPress plugin before 3.19.2 does not sanitise and escape the imported links from Google Sheet cells, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).
CVE-2025-68752: In the Linux kernel, the following vulnerability has been resolved:  iavf: Implement settime64 with -EOPNOTSUPP  ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference.  The fix is similar to commit 329d050bbe63 ("gve: Implement settime64 with -EOPNOTSUPP").
CVE-2025-68753: In the Linux kernel, the following vulnerability has been resolved:  ALSA: firewire-motu: add bounds check in put_user loop for DSP events  In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary.  Fix by adding a bounds check before put_user().
CVE-2025-68754: In the Linux kernel, the following vulnerability has been resolved:  rtc: amlogic-a4: fix double free caused by devm  The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free.  Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.
CVE-2025-68755: In the Linux kernel, the following vulnerability has been resolved:  staging: most: remove broken i2c driver  The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging.  Specifically, commit 723de0f9171e ("staging: most: remove device from interface structure") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.
CVE-2025-68758: In the Linux kernel, the following vulnerability has been resolved:  backlight: led-bl: Add devlink to supplier LEDs  LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device.  One consequence is that removal order is not correctly enforced.  Issues happen for example with the following sections in a device tree overlay:      // An LED driver chip     pca9632@62 {         compatible = "nxp,pca9632";         reg = <0x62>;   // ...          addon_led_pwm: led-pwm@3 {             reg = <3>;             label = "addon:led:pwm";         };     };      backlight-addon {         compatible = "led-backlight";         leds = <&addon_led_pwm>;         brightness-levels = <255>;         default-brightness-level = <255>;     };  In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter.  On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in:      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010     ...     Call trace:      led_put+0xe0/0x140      devm_led_release+0x6c/0x98  Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon):    echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind   echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind  Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.
CVE-2025-68759: In the Linux kernel, the following vulnerability has been resolved:  wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()  In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit.  Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.
CVE-2025-68760: In the Linux kernel, the following vulnerability has been resolved:  iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show  In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read.  If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read.  Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.
CVE-2025-68761: In the Linux kernel, the following vulnerability has been resolved:  hfs: fix potential use after free in hfs_correct_next_unused_CNID()  This code calls hfs_bnode_put(node) which drops the refcount and then dreferences "node" on the next line.  It's only safe to use "node" when we're holding a reference so flip these two lines around.
CVE-2025-68762: In the Linux kernel, the following vulnerability has been resolved:  net: netpoll: initialize work queue before error checks  Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue.  When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning.  Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.
CVE-2025-68763: In the Linux kernel, the following vulnerability has been resolved:  crypto: starfive - Correctly handle return of sg_nents_for_len  The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers.  Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.
CVE-2025-68765: In the Linux kernel, the following vulnerability has been resolved:  mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()  In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak.  Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.