xamxte/cve-to-cwe huggingface dataset:
CVE-2025-68209: In the Linux kernel, the following vulnerability has been resolved:  mlx5: Fix default values in create CQ  Currently, CQs without a completion function are assigned the mlx5_add_cq_to_tasklet function by default. This is problematic since only user CQs created through the mlx5_ib driver are intended to use this function.  Additionally, all CQs that will use doorbells instead of polling for completions must call mlx5_cq_arm. However, the default CQ creation flow leaves a valid value in the CQ's arm_db field, allowing FW to send interrupts to polling-only CQs in certain corner cases.  These two factors would allow a polling-only kernel CQ to be triggered by an EQ interrupt and call a completion function intended only for user CQs, causing a null pointer exception.  Some areas in the driver have prevented this issue with one-off fixes but did not address the root cause.  This patch fixes the described issue by adding defaults to the create CQ flow. It adds a default dummy completion function to protect against null pointer exceptions, and it sets an invalid command sequence number by default in kernel CQs to prevent the FW from sending an interrupt to the CQ until it is armed. User CQs are responsible for their own initialization values.  Callers of mlx5_core_create_cq are responsible for changing the completion function and arming the CQ per their needs.
CVE-2025-68210: In the Linux kernel, the following vulnerability has been resolved:  erofs: avoid infinite loop due to incomplete zstd-compressed data  Currently, the decompression logic incorrectly spins if compressed data is truncated in crafted (deliberately corrupted) images.
CVE-2025-68211: In the Linux kernel, the following vulnerability has been resolved:  ksm: use range-walk function to jump over holes in scan_get_next_rmap_item  Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages.  This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages.  This patch replaces the per-address lookup with a range walk using walk_page_range().  The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups.  This problem was previously discussed in [1].  Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page:  #include <unistd.h> #include <stdio.h> #include <sys/mman.h>  /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;  int main() {         char *area = mmap(NULL, size, PROT_READ | PROT_WRITE,                           MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0);          if (area == MAP_FAILED) {                 perror("mmap() failed\n");                 return -1;         }          /* Populate a single page such that we get an anon_vma. */         *area = 0;          /* Enable KSM. */         madvise(area, size, MADV_MERGEABLE);         pause();         return 0; }  $ ./ksm-sparse  & $ echo 1 > /sys/kernel/mm/ksm/run   Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page.  This makes ksmd essentially deadlocked not able to deduplicate anything of value.  With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.
CVE-2025-68212: In the Linux kernel, the following vulnerability has been resolved:  fs: Fix uninitialized 'offp' in statmount_string()  In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated.  Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.
CVE-2025-68213: In the Linux kernel, the following vulnerability has been resolved:  idpf: fix possible vport_config NULL pointer deref in remove  Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475]  <TASK> [ 1723.365972]  pci_device_remove+0x42/0xb0 [ 1723.366481]  device_release_driver_internal+0x1a9/0x210 [ 1723.366987]  pci_stop_bus_device+0x6d/0x90 [ 1723.367488]  pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971]  pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309]  sriov_disable+0x34/0xe0 [ 1723.368643]  idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982]  sriov_numvfs_store+0xda/0x1c0  Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.
CVE-2025-68217: In the Linux kernel, the following vulnerability has been resolved:  Input: pegasus-notetaker - fix potential out-of-bounds access  In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer.  Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.
CVE-2025-68219: In the Linux kernel, the following vulnerability has been resolved:  cifs: fix memory leak in smb3_fs_context_parse_param error path  Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues.  This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed.  The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak.  This issue was not addressed by commit e8c73eb7db0a ("cifs: client: fix memory leak in smb3_fs_context_parse_param"), which only fixed leaks from repeated fsconfig() calls but not this error path.  Patch updated with minor change suggested by kernel test robot
CVE-2025-68220: In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error  Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed):  Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c  [... TRIM...]  Call trace:  knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c  netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c  netcp_ndo_open from __dev_open+0x114/0x29c  __dev_open from __dev_change_flags+0x190/0x208  __dev_change_flags from netif_change_flags+0x1c/0x58  netif_change_flags from dev_change_flags+0x38/0xa0  dev_change_flags from ip_auto_config+0x2c4/0x11f0  ip_auto_config from do_one_initcall+0x58/0x200  do_one_initcall from kernel_init_freeable+0x1cc/0x238  kernel_init_freeable from kernel_init+0x1c/0x12c  kernel_init from ret_from_fork+0x14/0x38 [... TRIM...]  Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited.  Note, this change, in effect reverts commit 5b6cb43b4d62 ("net: ethernet: ti: netcp_core: return error while dma channel open issue"), but provides a less error prone implementation.
CVE-2025-68222: In the Linux kernel, the following vulnerability has been resolved:  pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc  s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx:          WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300         [...]         Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT)         [...]         Call trace:          __alloc_pages_noprof+0x290/0x300 (P)          ___kmalloc_large_node+0x84/0x168          __kmalloc_large_node_noprof+0x34/0x120          __kmalloc_noprof+0x2ac/0x378          pinconf_generic_parse_dt_config+0x68/0x1a0          s32_dt_node_to_map+0x104/0x248          dt_to_map_one_config+0x154/0x1d8          pinctrl_dt_to_map+0x12c/0x280          create_pinctrl+0x6c/0x270          pinctrl_get+0xc0/0x170          devm_pinctrl_get+0x50/0xa0          pinctrl_bind_pins+0x60/0x2a0          really_probe+0x60/0x3a0         [...]          __platform_driver_register+0x2c/0x40          i2c_adap_imx_init+0x28/0xff8 [i2c_imx]         [...]  This results in later parse failures that can cause issues in dependent drivers:          s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property         s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property         [...]         pca953x 0-0022: failed writing register: -6         i2c i2c-0: IMX I2C adapter registered         s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property         s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property         i2c i2c-1: IMX I2C adapter registered         s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property         s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property         i2c i2c-2: IMX I2C adapter registered  Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.
CVE-2025-68226: In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix incomplete backport in cfids_invalidation_worker()  The previous commit bdb596ceb4b7 ("smb: client: fix potential UAF in smb2_close_cached_fid()") was an incomplete backport and missed one kref_put() call in cfids_invalidation_worker() that should have been converted to close_cached_dir().
CVE-2025-68228: In the Linux kernel, the following vulnerability has been resolved:  drm/plane: Fix create_in_format_blob() return value  create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.
CVE-2025-68229: In the Linux kernel, the following vulnerability has been resolved:  scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()  If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.    Unable to allocate struct scsi_host   BUG: kernel NULL pointer dereference, address: 0000000000000194   #PF: supervisor read access in kernel mode   #PF: error_code(0x0000) - not-present page   PGD 0 P4D 0   Oops: 0000 [#1] PREEMPT SMP NOPTI   CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1   Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024   RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ...   Call Trace:    <TASK>    configfs_read_iter+0x12d/0x1d0 [configfs]    vfs_read+0x1b5/0x300    ksys_read+0x6f/0xf0 ...
CVE-2025-68231: In the Linux kernel, the following vulnerability has been resolved:  mm/mempool: fix poisoning order>0 pages with HIGHMEM  The kernel test has reported:    BUG: unable to handle page fault for address: fffba000   #PF: supervisor write access in kernel mode   #PF: error_code(0x0002) - not-present page   *pde = 03171067 *pte = 00000000   Oops: Oops: 0002 [#1]   CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G                T   6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE  a1d066dfe789f54bc7645c7989957d2bdee593ca   Tainted: [T]=RANDSTRUCT   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014   EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)   Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56   EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b   ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8   DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287   CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690   Call Trace:    poison_element (mm/mempool.c:83 mm/mempool.c:102)    mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)    mempool_init_noprof (mm/mempool.c:250 (discriminator 1))    ? mempool_alloc_pages (mm/mempool.c:640)    bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))    ? mempool_alloc_pages (mm/mempool.c:640)    do_one_initcall (init/main.c:1283)  Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed.  We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.
CVE-2025-68232: In the Linux kernel, the following vulnerability has been resolved:  veth: more robust handing of race to avoid txq getting stuck  Commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max).  The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a "lost wakeup" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts.  This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy.  This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer:  (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ.   This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI.  (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion.   This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI.  Then veth_poll() change rx_notify_masked to false and stops NAPI.  Before exiting veth_poll() will observe TXQ is stopped and wake it up.
CVE-2025-68233: In the Linux kernel, the following vulnerability has been resolved:  drm/tegra: Add call to put_pid()  Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking.  [mperttunen@nvidia.com: reword commit message]
CVE-2025-68235: In the Linux kernel, the following vulnerability has been resolved:  nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot  nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning.  Make sure this data is deallocated.
CVE-2025-68237: In the Linux kernel, the following vulnerability has been resolved:  mtdchar: fix integer overflow in read/write ioctls  The "req.start" and "req.len" variables are u64 values that come from the user at the start of the function.  We mask away the high 32 bits of "req.len" so that's capped at U32_MAX but the "req.start" variable can go up to U64_MAX which means that the addition can still integer overflow.  Use check_add_overflow() to fix this bug.
CVE-2025-68238: In the Linux kernel, the following vulnerability has been resolved:  mtd: rawnand: cadence: fix DMA device NULL pointer dereference  The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized.  Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.
CVE-2025-68241: In the Linux kernel, the following vulnerability has been resolved:  ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe  The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random.  The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked.  CPU 0                             CPU 1 __mkroute_output()   find_exception() [fnheX]                                   update_or_create_fnhe()                                     fnhe_remove_oldest() [fnheX]   rt_bind_exception() [bind dst]                                   RCU callback [fnheX freed, dst leak]  This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device:    unregister_netdevice: waiting for sitX to become free. Usage count = N  Ido Schimmel provided the simple test validation method [1].  The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed.  [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \     local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \     -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \     -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1
CVE-2025-68245: In the Linux kernel, the following vulnerability has been resolved:  net: netpoll: fix incorrect refcount handling causing incorrect cleanup  commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks.  Scenario causing lack of proper cleanup:  1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is    allocated, and refcnt = 1    - Keep in mind that npinfo is shared among all netpoll instances. In      this case, there is just one.  2) Another netpoll is also associated with the same NIC and    npinfo->refcnt += 1.    - Now dev->npinfo->refcnt = 2;    - There is just one npinfo associated to the netdev.  3) When the first netpolls goes to clean up:    - The first cleanup succeeds and clears np->dev->npinfo, ignoring      refcnt.      - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);`    - Set dev->npinfo = NULL, without proper cleanup    - No ->ndo_netpoll_cleanup() is either called  4) Now the second target tries to clean up    - The second cleanup fails because np->dev->npinfo is already NULL.      * In this case, ops->ndo_netpoll_cleanup() was never called, and        the skb pool is not cleaned as well (for the second netpoll        instance)   - This leaks npinfo and skbpool skbs, which is clearly reported by     kmemleak.  Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.
CVE-2025-68246: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: close accepted socket when per-IP limit rejects connection  When the per-IP connection limit is exceeded in ksmbd_kthread_fn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS.  Release client_sk before continuing.  This bug was found with ZeroPath.
CVE-2025-68247: In the Linux kernel, the following vulnerability has been resolved:  posix-timers: Plug potential memory leak in do_timer_create()  When posix timer creation is set to allocate a given timer ID and the access to the user space value faults, the function terminates without freeing the already allocated posix timer structure.  Move the allocation after the user space access to cure that.  [ tglx: Massaged change log ]