xamxte/cve-to-cwe huggingface dataset:
CVE-2026-22997: In the Linux kernel, the following vulnerability has been resolved:  net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts  Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as  | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.  problem.
CVE-2026-22999: In the Linux kernel, the following vulnerability has been resolved:  net/sched: sch_qfq: do not free existing class in qfq_change_class()  Fixes qfq_change_class() error case.  cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.
CVE-2026-23001: In the Linux kernel, the following vulnerability has been resolved:  macvlan: fix possible UAF in macvlan_forward_source()  Add RCU protection on (struct macvlan_source_entry)->vlan.  Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts.  This allows macvlan_forward_source() to skip over entries queued for freeing.  Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)).  https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u
CVE-2026-23006: In the Linux kernel, the following vulnerability has been resolved:  ASoC: tlv320adcx140: fix null pointer  The "snd_soc_component" in "adcx140_priv" was only used once but never set. It was only used for reaching "dev" which is already present in "adcx140_priv".
CVE-2026-23007: In the Linux kernel, the following vulnerability has been resolved:  block: zero non-PI portion of auto integrity buffer  The auto-generated integrity buffer for writes needs to be fully initialized before being passed to the underlying block device, otherwise the uninitialized memory can be read back by userspace or anyone with physical access to the storage device. If protection information is generated, that portion of the integrity buffer is already initialized. The integrity data is also zeroed if PI generation is disabled via sysfs or the PI tuple size is 0. However, this misses the case where PI is generated and the PI tuple size is nonzero, but the metadata size is larger than the PI tuple. In this case, the remainder ("opaque") of the metadata is left uninitialized. Generalize the BLK_INTEGRITY_CSUM_NONE check to cover any case when the metadata is larger than just the PI tuple.
CVE-2026-23008: In the Linux kernel, the following vulnerability has been resolved:  drm/vmwgfx: Fix KMS with 3D on HW version 10  HW version 10 does not have GB Surfaces so there is no backing buffer for surface backed FBs. This would result in a nullptr dereference and crash the driver causing a black screen.
CVE-2026-23009: In the Linux kernel, the following vulnerability has been resolved:  xhci: sideband: don't dereference freed ring when removing sideband endpoint  xhci_sideband_remove_endpoint() incorrecly assumes that the endpoint is running and has a valid transfer ring.  Lianqin reported a crash during suspend/wake-up stress testing, and found the cause to be dereferencing a non-existing transfer ring 'ep->ring' during xhci_sideband_remove_endpoint().  The endpoint and its ring may be in unknown state if this function is called after xHCI was reinitialized in resume (lost power), or if device is being re-enumerated, disconnected or endpoint already dropped.  Fix this by both removing unnecessary ring access, and by checking ep->ring exists before dereferencing it. Also make sure endpoint is running before attempting to stop it.  Remove the xhci_initialize_ring_info() call during sideband endpoint removal as is it only initializes ring structure enqueue, dequeue and cycle state values to their starting values without changing actual hardware enqueue, dequeue and cycle state. Leaving them out of sync is worse than leaving it as it is. The endpoint will get freed in after this in most usecases.  If the (audio) class driver want's to reuse the endpoint after offload then it is up to the class driver to ensure endpoint is properly set up.
CVE-2026-23011: In the Linux kernel, the following vulnerability has been resolved:  ipv4: ip_gre: make ipgre_header() robust  Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")  Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1].  This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len  In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device.  [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0  kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work  RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace:  <TASK>   skb_under_panic net/core/skbuff.c:223 [inline]   skb_push+0xc3/0xe0 net/core/skbuff.c:2641   ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897   dev_hard_header include/linux/netdevice.h:3436 [inline]   neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618   NF_HOOK_COND include/linux/netfilter.h:307 [inline]   ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247   NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318   mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855   mld_send_cr net/ipv6/mcast.c:2154 [inline]   mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693   process_one_work kernel/workqueue.c:3257 [inline]   process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340   worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421   kthread+0x711/0x8a0 kernel/kthread.c:463   ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
CVE-2026-23012: In the Linux kernel, the following vulnerability has been resolved:  mm/damon/core: remove call_control in inactive contexts  If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context's call_controls list.  Let's suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context.  The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated.  As a result, use-after-free happens.  This can actually be triggered using the DAMON sysfs interface.  It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though.  Please refer to the report for more details about the issue reproduction steps.  Fix the issue by making two changes.  Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx->kdamond reset.  This makes any code that sees NULL ctx->kdamond can safely assume the context may not access damon_call() requests anymore.  Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.
CVE-2026-23013: In the Linux kernel, the following vulnerability has been resolved:  net: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollback  octep_vf_request_irqs() requests MSI-X queue IRQs with dev_id set to ioq_vector. If request_irq() fails part-way, the rollback loop calls free_irq() with dev_id set to 'oct', which does not match the original dev_id and may leave the irqaction registered.  This can keep IRQ handlers alive while ioq_vector is later freed during unwind/teardown, leading to a use-after-free or crash when an interrupt fires.  Fix the error path to free IRQs with the same ioq_vector dev_id used during request_irq().
CVE-2025-14316: The AhaChat Messenger Marketing WordPress plugin through 1.1 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-57783: Improper header parsing may lead to request smuggling has been identified in Hiawatha webserver version 11.7 which allows an unauthenticated attacker to access restricted resources managed by Hiawatha webserver.
CVE-2025-57784: Tomahawk auth timing attack due to usage of `strcmp` has been identified in Hiawatha webserver version 11.7 which allows a local attacker to access the management client.
CVE-2026-1504: Inappropriate implementation in Background Fetch API in Google Chrome prior to 144.0.7559.110 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)
CVE-2025-13471: The User Activity Log WordPress plugin through 2.2 does not properly handle failed login attempts in some cases, allowing unauthenticated users to set arbitrary options to 1 (for example to enable User Registration when it has been turned off)
CVE-2025-61731: Building a malicious file with cmd/go can cause can cause a write to an attacker-controlled file with partial control of the file content. The "#cgo pkg-config:" directive in a Go source file provides command-line arguments to provide to the Go pkg-config command. An attacker can provide a "--log-file" argument to this directive, causing pkg-config to write to an attacker-controlled location.
CVE-2025-71181: In the Linux kernel, the following vulnerability has been resolved:  rust_binder: remove spin_lock() in rust_shrink_free_page()  When forward-porting Rust Binder to 6.18, I neglected to take commit fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into account, and apparently I did not end up running the shrinker callback when I sanity tested the driver before submission. This leads to crashes like the following:   ============================================  WARNING: possible recursive locking detected  6.18.0-mainline-maybe-dirty #1 Tainted: G          IO  --------------------------------------------  kswapd0/68 is trying to acquire lock:  ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230   but task is already holding lock:  ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20   other info that might help us debug this:   Possible unsafe locking scenario:          CPU0         ----    lock(&l->lock);    lock(&l->lock);    *** DEADLOCK ***    May be due to missing lock nesting notation   3 locks held by kswapd0/68:   #0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160   #1: ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20   #2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230  To fix this, remove the spin_lock() call from rust_shrink_free_page().
CVE-2025-71182: In the Linux kernel, the following vulnerability has been resolved:  can: j1939: make j1939_session_activate() fail if device is no longer registered  syzbot is still reporting    unregister_netdevice: waiting for vcan0 to become free. Usage count = 2  even after commit 93a27b5891b8 ("can: j1939: add missing calls in NETDEV_UNREGISTER notification handler") was added. A debug printk() patch found that j1939_session_activate() can succeed even after j1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER) has completed.  Since j1939_cancel_active_session() is processed with the session list lock held, checking ndev->reg_state in j1939_session_activate() with the session list lock held can reliably close the race window.
CVE-2025-71184: In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix NULL dereference on root when tracing inode eviction  When evicting an inode the first thing we do is to setup tracing for it, which implies fetching the root's id. But in btrfs_evict_inode() the root might be NULL, as implied in the next check that we do in btrfs_evict_inode().  Hence, we either should set the ->root_objectid to 0 in case the root is NULL, or we move tracing setup after checking that the root is not NULL. Setting the rootid to 0 at least gives us the possibility to trace this call even in the case when the root is NULL, so that's the solution taken here.
CVE-2025-71185: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation  Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.
CVE-2025-71187: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: sh: rz-dmac: fix device leak on probe failure  Make sure to drop the reference taken when looking up the ICU device during probe also on probe failures (e.g. probe deferral).
CVE-2025-71189: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: dw: dmamux: fix OF node leak on route allocation failure  Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.
CVE-2025-71190: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: bcm-sba-raid: fix device leak on probe  Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.
CVE-2025-71191: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: at_hdmac: fix device leak on of_dma_xlate()  Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources.  Note that commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.
CVE-2026-23015: In the Linux kernel, the following vulnerability has been resolved:  gpio: mpsse: fix reference leak in gpio_mpsse_probe() error paths  The reference obtained by calling usb_get_dev() is not released in the gpio_mpsse_probe() error paths. Fix that by using device managed helper functions. Also remove the usb_put_dev() call in the disconnect function since now it will be released automatically.
CVE-2026-23017: In the Linux kernel, the following vulnerability has been resolved:  idpf: fix error handling in the init_task on load  If the init_task fails during a driver load, we end up without vports and netdevs, effectively failing the entire process. In that state a subsequent reset will result in a crash as the service task attempts to access uninitialized resources. Following trace is from an error in the init_task where the CREATE_VPORT (op 501) is rejected by the FW:  [40922.763136] idpf 0000:83:00.0: Device HW Reset initiated [40924.449797] idpf 0000:83:00.0: Transaction failed (op 501) [40958.148190] idpf 0000:83:00.0: HW reset detected [40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8 ... [40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf] [40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf] ... [40958.177932] Call Trace: [40958.178491]  <TASK> [40958.179040]  process_one_work+0x226/0x6d0 [40958.179609]  worker_thread+0x19e/0x340 [40958.180158]  ? __pfx_worker_thread+0x10/0x10 [40958.180702]  kthread+0x10f/0x250 [40958.181238]  ? __pfx_kthread+0x10/0x10 [40958.181774]  ret_from_fork+0x251/0x2b0 [40958.182307]  ? __pfx_kthread+0x10/0x10 [40958.182834]  ret_from_fork_asm+0x1a/0x30 [40958.183370]  </TASK>  Fix the error handling in the init_task to make sure the service and mailbox tasks are disabled if the error happens during load. These are started in idpf_vc_core_init(), which spawns the init_task and has no way of knowing if it failed. If the error happens on reset, following successful driver load, the tasks can still run, as that will allow the netdevs to attempt recovery through another reset. Stop the PTP callbacks either way as those will be restarted by the call to idpf_vc_core_init() during a successful reset.
CVE-2026-23019: In the Linux kernel, the following vulnerability has been resolved:  net: marvell: prestera: fix NULL dereference on devlink_alloc() failure  devlink_alloc() may return NULL on allocation failure, but prestera_devlink_alloc() unconditionally calls devlink_priv() on the returned pointer.  This leads to a NULL pointer dereference if devlink allocation fails. Add a check for a NULL devlink pointer and return NULL early to avoid the crash.
CVE-2026-23020: In the Linux kernel, the following vulnerability has been resolved:  net: 3com: 3c59x: fix possible null dereference in vortex_probe1()  pdev can be null and free_ring: can be called in 1297 with a null pdev.
CVE-2026-23021: In the Linux kernel, the following vulnerability has been resolved:  net: usb: pegasus: fix memory leak in update_eth_regs_async()  When asynchronously writing to the device registers and if usb_submit_urb() fail, the code fail to release allocated to this point resources.
CVE-2026-23022: In the Linux kernel, the following vulnerability has been resolved:  idpf: fix memory leak in idpf_vc_core_deinit()  Make sure to free hw->lan_regs. Reported by kmemleak during reset:  unreferenced object 0xff1b913d02a936c0 (size 96):   comm "kworker/u258:14", pid 2174, jiffies 4294958305   hex dump (first 32 bytes):     00 00 00 c0 a8 ba 2d ff 00 00 00 00 00 00 00 00  ......-.........     00 00 40 08 00 00 00 00 00 00 25 b3 a8 ba 2d ff  ..@.......%...-.   backtrace (crc 36063c4f):     __kmalloc_noprof+0x48f/0x890     idpf_vc_core_init+0x6ce/0x9b0 [idpf]     idpf_vc_event_task+0x1fb/0x350 [idpf]     process_one_work+0x226/0x6d0     worker_thread+0x19e/0x340     kthread+0x10f/0x250     ret_from_fork+0x251/0x2b0     ret_from_fork_asm+0x1a/0x30
CVE-2026-23023: In the Linux kernel, the following vulnerability has been resolved:  idpf: fix memory leak in idpf_vport_rel()  Free vport->rx_ptype_lkup in idpf_vport_rel() to avoid leaking memory during a reset. Reported by kmemleak:  unreferenced object 0xff450acac838a000 (size 4096):   comm "kworker/u258:5", pid 7732, jiffies 4296830044   hex dump (first 32 bytes):     00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00  ................     00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00  ................   backtrace (crc 3da81902):     __kmalloc_cache_noprof+0x469/0x7a0     idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf]     idpf_init_task+0x1ec/0x8d0 [idpf]     process_one_work+0x226/0x6d0     worker_thread+0x19e/0x340     kthread+0x10f/0x250     ret_from_fork+0x251/0x2b0     ret_from_fork_asm+0x1a/0x30
CVE-2026-23024: In the Linux kernel, the following vulnerability has been resolved:  idpf: fix memory leak of flow steer list on rmmod  The flow steering list maintains entries that are added and removed as ethtool creates and deletes flow steering rules. Module removal with active entries causes memory leak as the list is not properly cleaned up.  Prevent this by iterating through the remaining entries in the list and freeing the associated memory during module removal. Add a spinlock (flow_steer_list_lock) to protect the list access from multiple threads.
CVE-2026-23026: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()  Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails.  The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the    reference to the original memory 4. The original memory becomes unreachable and cannot be freed  Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds.  Found via static analysis and code review.
CVE-2026-23027: In the Linux kernel, the following vulnerability has been resolved:  LoongArch: KVM: Fix kvm_device leak in kvm_pch_pic_destroy()  In kvm_ioctl_create_device(), kvm_device has allocated memory, kvm_device->destroy() seems to be supposed to free its kvm_device struct, but kvm_pch_pic_destroy() is not currently doing this, that would lead to a memory leak.  So, fix it.
CVE-2026-23028: In the Linux kernel, the following vulnerability has been resolved:  LoongArch: KVM: Fix kvm_device leak in kvm_ipi_destroy()  In kvm_ioctl_create_device(), kvm_device has allocated memory, kvm_device->destroy() seems to be supposed to free its kvm_device struct, but kvm_ipi_destroy() is not currently doing this, that would lead to a memory leak.  So, fix it.
CVE-2026-23029: In the Linux kernel, the following vulnerability has been resolved:  LoongArch: KVM: Fix kvm_device leak in kvm_eiointc_destroy()  In kvm_ioctl_create_device(), kvm_device has allocated memory, kvm_device->destroy() seems to be supposed to free its kvm_device struct, but kvm_eiointc_destroy() is not currently doing this, that would lead to a memory leak.  So, fix it.
CVE-2026-23030: In the Linux kernel, the following vulnerability has been resolved:  phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()  The for_each_available_child_of_node() calls of_node_put() to release child_np in each success loop. After breaking from the loop with the child_np has been released, the code will jump to the put_child label and will call the of_node_put() again if the devm_request_threaded_irq() fails. These cause a double free bug.  Fix by returning directly to avoid the duplicate of_node_put().
CVE-2026-23031: In the Linux kernel, the following vulnerability has been resolved:  can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak  In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted).  However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close().  Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.
CVE-2026-23032: In the Linux kernel, the following vulnerability has been resolved:  null_blk: fix kmemleak by releasing references to fault configfs items  When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk driver sets up fault injection support by creating the timeout_inject, requeue_inject, and init_hctx_fault_inject configfs items as children of the top-level nullbX configfs group.  However, when the nullbX device is removed, the references taken to these fault-config configfs items are not released. As a result, kmemleak reports a memory leak, for example:  unreferenced object 0xc00000021ff25c40 (size 32):   comm "mkdir", pid 10665, jiffies 4322121578   hex dump (first 32 bytes):     69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f  init_hctx_fault_     69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00  inject..........   backtrace (crc 1a018c86):     __kmalloc_node_track_caller_noprof+0x494/0xbd8     kvasprintf+0x74/0xf4     config_item_set_name+0xf0/0x104     config_group_init_type_name+0x48/0xfc     fault_config_init+0x48/0xf0     0xc0080000180559e4     configfs_mkdir+0x304/0x814     vfs_mkdir+0x49c/0x604     do_mkdirat+0x314/0x3d0     sys_mkdir+0xa0/0xd8     system_call_exception+0x1b0/0x4f0     system_call_vectored_common+0x15c/0x2ec  Fix this by explicitly releasing the references to the fault-config configfs items when dropping the reference to the top-level nullbX configfs group.