xamxte/cve-to-cwe huggingface dataset:
CVE-2025-40028: In the Linux kernel, the following vulnerability has been resolved:  binder: fix double-free in dbitmap  A process might fail to allocate a new bitmap when trying to expand its proc->dmap. In that case, dbitmap_grow() fails and frees the old bitmap via dbitmap_free(). However, the driver calls dbitmap_free() again when the same process terminates, leading to a double-free error:    ==================================================================   BUG: KASAN: double-free in binder_proc_dec_tmpref+0x2e0/0x55c   Free of addr ffff00000b7c1420 by task kworker/9:1/209    CPU: 9 UID: 0 PID: 209 Comm: kworker/9:1 Not tainted 6.17.0-rc6-dirty #5 PREEMPT   Hardware name: linux,dummy-virt (DT)   Workqueue: events binder_deferred_func   Call trace:    kfree+0x164/0x31c    binder_proc_dec_tmpref+0x2e0/0x55c    binder_deferred_func+0xc24/0x1120    process_one_work+0x520/0xba4   [...]    Allocated by task 448:    __kmalloc_noprof+0x178/0x3c0    bitmap_zalloc+0x24/0x30    binder_open+0x14c/0xc10   [...]    Freed by task 449:    kfree+0x184/0x31c    binder_inc_ref_for_node+0xb44/0xe44    binder_transaction+0x29b4/0x7fbc    binder_thread_write+0x1708/0x442c    binder_ioctl+0x1b50/0x2900   [...]   ==================================================================  Fix this issue by marking proc->map NULL in dbitmap_free().
CVE-2025-40029: In the Linux kernel, the following vulnerability has been resolved:  bus: fsl-mc: Check return value of platform_get_resource()  platform_get_resource() returns NULL in case of failure, so check its return value and propagate the error in order to prevent NULL pointer dereference.
CVE-2025-40030: In the Linux kernel, the following vulnerability has been resolved:  pinctrl: check the return value of pinmux_ops::get_function_name()  While the API contract in docs doesn't specify it explicitly, the generic implementation of the get_function_name() callback from struct pinmux_ops - pinmux_generic_get_function_name() - can fail and return NULL. This is already checked in pinmux_check_ops() so add a similar check in pinmux_func_name_to_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions.
CVE-2025-40031: In the Linux kernel, the following vulnerability has been resolved:  tee: fix register_shm_helper()  In register_shm_helper(), fix incorrect error handling for a call to iov_iter_extract_pages(). A case is missing for when iov_iter_extract_pages() only got some pages and return a number larger than 0, but not the requested amount.  This fixes a possible NULL pointer dereference following a bad input from ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped.
CVE-2025-40032: In the Linux kernel, the following vulnerability has been resolved:  PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release  The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan().  Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases:    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050   Call trace:    dma_release_channel+0x2c/0x120 (P)    pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test]    pci_epc_deinit_notify+0x74/0xc0    tegra_pcie_ep_pex_rst_irq+0x250/0x5d8    irq_thread_fn+0x34/0xb8    irq_thread+0x18c/0x2e8    kthread+0x14c/0x210    ret_from_fork+0x10/0x20  [mani: trimmed the stack trace]
CVE-2025-40033: In the Linux kernel, the following vulnerability has been resolved:  remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()  pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULL check, which could lead to a null pointer dereference. Move the pru assignment, ensuring we never dereference a NULL rproc pointer.
CVE-2025-40034: In the Linux kernel, the following vulnerability has been resolved:  PCI/AER: Avoid NULL pointer dereference in aer_ratelimit()  When platform firmware supplies error information to the OS, e.g., via the ACPI APEI GHES mechanism, it may identify an error source device that doesn't advertise an AER Capability and therefore dev->aer_info, which contains AER stats and ratelimiting data, is NULL.  pci_dev_aer_stats_incr() already checks dev->aer_info for NULL, but aer_ratelimit() did not, leading to NULL pointer dereferences like this one from the URL below:    {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0   {1}[Hardware Error]: event severity: corrected   {1}[Hardware Error]:   device_id: 0000:00:00.0   {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2020   {1}[Hardware Error]:   aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000   BUG: kernel NULL pointer dereference, address: 0000000000000264   RIP: 0010:___ratelimit+0xc/0x1b0   pci_print_aer+0x141/0x360   aer_recover_work_func+0xb5/0x130  [8086:2020] is an Intel "Sky Lake-E DMI3 Registers" device that claims to be a Root Port but does not advertise an AER Capability.  Add a NULL check in aer_ratelimit() to avoid the NULL pointer dereference. Note that this also prevents ratelimiting these events from GHES.  [bhelgaas: add crash details to commit log]
CVE-2025-40035: In the Linux kernel, the following vulnerability has been resolved:  Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak  Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace.  Initialize ff_up_compat to zero before filling valid fields.
CVE-2025-40036: In the Linux kernel, the following vulnerability has been resolved:  misc: fastrpc: fix possible map leak in fastrpc_put_args  copy_to_user() failure would cause an early return without cleaning up the fdlist, which has been updated by the DSP. This could lead to map leak. Fix this by redirecting to a cleanup path on failure, ensuring that all mapped buffers are properly released before returning.
CVE-2025-40040: In the Linux kernel, the following vulnerability has been resolved:  mm/ksm: fix flag-dropping behavior in ksm_madvise  syzkaller discovered the following crash: (kernel BUG)  [   44.607039] ------------[ cut here ]------------ [   44.607422] kernel BUG at mm/userfaultfd.c:2067! [   44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [   44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [   44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [   44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460  <snip other registers, drop unreliable trace>  [   44.617726] Call Trace: [   44.617926]  <TASK> [   44.619284]  userfaultfd_release+0xef/0x1b0 [   44.620976]  __fput+0x3f9/0xb60 [   44.621240]  fput_close_sync+0x110/0x210 [   44.622222]  __x64_sys_close+0x8f/0x120 [   44.622530]  do_syscall_64+0x5b/0x2f0 [   44.622840]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [   44.623244] RIP: 0033:0x7f365bb3f227  Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all().  Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.  The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.  Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide.  This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.  VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000.  After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation.  This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.  Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the BIT() macro.  Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.  Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:  [   45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067  but the root-cause (flag-drop) remains the same.  [akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]
CVE-2025-40043: In the Linux kernel, the following vulnerability has been resolved:  net: nfc: nci: Add parameter validation for packet data  Syzbot reported an uninitialized value bug in nci_init_req, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").  This bug arises due to very limited and poor input validation that was done at nic_valid_size(). This validation only validates the skb->len (directly reflects size provided at the userspace interface) with the length provided in the buffer itself (interpreted as NCI_HEADER). This leads to the processing of memory content at the address assuming the correct layout per what opcode requires there. This leads to the accesses to buffer of `skb_buff->data` which is not assigned anything yet.  Following the same silent drop of packets of invalid sizes at `nic_valid_size()`, add validation of the data in the respective handlers and return error values in case of failure. Release the skb if error values are returned from handlers in `nci_nft_packet` and effectively do a silent drop  Possible TODO: because we silently drop the packets, the call to `nci_request` will be waiting for completion of request and will face timeouts. These timeouts can get excessively logged in the dmesg. A proper handling of them may require to export `nci_request_cancel` (or propagate error handling from the nft packets handlers).
CVE-2025-40044: In the Linux kernel, the following vulnerability has been resolved:  fs: udf: fix OOB read in lengthAllocDescs handling  When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read.  BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309  CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60  udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261  udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179  extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46  udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106  udf_release_file+0xc1/0x120 fs/udf/file.c:185  __fput+0x23f/0x880 fs/file_table.c:431  task_work_run+0x24f/0x310 kernel/task_work.c:239  exit_task_work include/linux/task_work.h:43 [inline]  do_exit+0xa2f/0x28e0 kernel/exit.c:939  do_group_exit+0x207/0x2c0 kernel/exit.c:1088  __do_sys_exit_group kernel/exit.c:1099 [inline]  __se_sys_exit_group kernel/exit.c:1097 [inline]  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  </TASK>  Validate the computed total length against epos->bh->b_size.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-40045: In the Linux kernel, the following vulnerability has been resolved:  ASoC: codecs: wcd937x: set the comp soundwire port correctly  For some reason we endup with setting soundwire port for HPHL_COMP and HPHR_COMP as zero, this can potentially result in a memory corruption due to accessing and setting -1 th element of port_map array.
CVE-2025-40046: In the Linux kernel, the following vulnerability has been resolved:  io_uring/zcrx: fix overshooting recv limit  It's reported that sometimes a zcrx request can receive more than was requested. It's caused by io_zcrx_recv_skb() adjusting desc->count for all received buffers including frag lists, but then doing recursive calls to process frag list skbs, which leads to desc->count double accounting and underflow.
CVE-2025-40049: In the Linux kernel, the following vulnerability has been resolved:  Squashfs: fix uninit-value in squashfs_get_parent  Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.  This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number.  In particular the inode number is that of a symbolic link, rather than a directory.  Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field.   unsigned int parent_ino = squashfs_i(inode)->parent;  Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access.  The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned.  Regular inodes used to share the parent field with the block_list_start field.  This is removed in this commit to enable the parent field to contain the invalid inode number 0.
CVE-2025-40053: In the Linux kernel, the following vulnerability has been resolved:  net: dlink: handle copy_thresh allocation failure  The driver did not handle failure of `netdev_alloc_skb_ip_align()`. If the allocation failed, dereferencing `skb->protocol` could lead to a NULL pointer dereference.  This patch tries to allocate `skb`. If the allocation fails, it falls back to the normal path.  Tested-on: D-Link DGE-550T Rev-A3
CVE-2025-40054: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix UAF issue in f2fs_merge_page_bio()  As JY reported in bugzilla [1],  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98 lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4 CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P    B   W  OE      6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5 Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Workqueue: writeback wb_workfn (flush-254:49) Call trace:  f2fs_is_cp_guaranteed+0x70/0x98  f2fs_inplace_write_data+0x174/0x2f4  f2fs_do_write_data_page+0x214/0x81c  f2fs_write_single_data_page+0x28c/0x764  f2fs_write_data_pages+0x78c/0xce4  do_writepages+0xe8/0x2fc  __writeback_single_inode+0x4c/0x4b4  writeback_sb_inodes+0x314/0x540  __writeback_inodes_wb+0xa4/0xf4  wb_writeback+0x160/0x448  wb_workfn+0x2f0/0x5dc  process_scheduled_works+0x1c8/0x458  worker_thread+0x334/0x3f0  kthread+0x118/0x1ac  ret_from_fork+0x10/0x20  [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575  The panic was caused by UAF issue w/ below race condition:  kworker - writepages  - f2fs_write_cache_pages   - f2fs_write_single_data_page    - f2fs_do_write_data_page     - f2fs_inplace_write_data      - f2fs_merge_page_bio       - add_inu_page       : cache page #1 into bio & cache bio in         io->bio_list   - f2fs_write_single_data_page    - f2fs_do_write_data_page     - f2fs_inplace_write_data      - f2fs_merge_page_bio       - add_inu_page       : cache page #2 into bio which is linked         in io->bio_list       write       - f2fs_write_begin       : write page #1        - f2fs_folio_wait_writeback         - f2fs_submit_merged_ipu_write          - f2fs_submit_write_bio          : submit bio which inclues page #1 and #2        software IRQ       - f2fs_write_end_io        - fscrypt_free_bounce_page        : freed bounced page which belongs to page #2       - inc_page_count( , WB_DATA_TYPE(data_folio), false)       : data_folio points to fio->encrypted_page         the bounced page can be freed before         accessing it in f2fs_is_cp_guarantee()  It can reproduce w/ below testcase: Run below script in shell #1: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync"  Run below script in shell #2: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync"  So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after commit page into internal ipu cache.
CVE-2025-40055: In the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix double free in user_cluster_connect()  user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time.  Set "lc" to NULL on this path to avoid a double free.
CVE-2025-40057: In the Linux kernel, the following vulnerability has been resolved:  ptp: Add a upper bound on max_vclocks  syzbot reported WARNING in max_vclocks_store.  This occurs when the argument max is too large for kcalloc to handle.  Extend the guard to guard against values that are too large for kcalloc
CVE-2025-40059: In the Linux kernel, the following vulnerability has been resolved:  coresight: Fix incorrect handling for return value of devm_kzalloc  The return value of devm_kzalloc could be an null pointer, use "!desc.pdata" to fix incorrect handling return value of devm_kzalloc.
CVE-2025-40060: In the Linux kernel, the following vulnerability has been resolved:  coresight: trbe: Return NULL pointer for allocation failures  When the TRBE driver fails to allocate a buffer, it currently returns the error code "-ENOMEM". However, the caller etm_setup_aux() only checks for a NULL pointer, so it misses the error. As a result, the driver continues and eventually causes a kernel panic.  Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on allocation failures. This allows that the callers can properly handle the failure.
CVE-2025-40061: In the Linux kernel, the following vulnerability has been resolved:  RDMA/rxe: Fix race in do_task() when draining  When do_task() exhausts its iteration budget (!ret), it sets the state to TASK_STATE_IDLE to reschedule, without a secondary check on the current task->state. This can overwrite the TASK_STATE_DRAINING state set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().  While state changes are protected by a spinlock, both rxe_cleanup_task() and rxe_disable_task() release the lock while waiting for the task to finish draining in the while(!is_done(task)) loop. The race occurs if do_task() hits its iteration limit and acquires the lock in this window. The cleanup logic may then proceed while the task incorrectly reschedules itself, leading to a potential use-after-free.  This bug was introduced during the migration from tasklets to workqueues, where the special handling for the draining case was lost.  Fix this by restoring the original pre-migration behavior. If the state is TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the task to finish its work, so that a subsequent iteration can reach the switch statement and correctly transition the state to TASK_STATE_DRAINED, stopping the task as intended.
CVE-2025-40062: In the Linux kernel, the following vulnerability has been resolved:  crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs  When the initialization of qm->debug.acc_diff_reg fails, the probe process does not exit. However, after qm->debug.qm_diff_regs is freed, it is not set to NULL. This can lead to a double free when the remove process attempts to free it again. Therefore, qm->debug.qm_diff_regs should be set to NULL after it is freed.
CVE-2025-40066: In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7996: Check phy before init msta_link in mt7996_mac_sta_add_links()  In order to avoid a possible NULL pointer dereference in mt7996_mac_sta_init_link routine, move the phy pointer check before running mt7996_mac_sta_init_link() in mt7996_mac_sta_add_links routine.
CVE-2025-40067: In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist  Index allocation requires at least one bit in the $BITMAP attribute to track usage of index entries. If the bitmap is empty while index blocks are already present, this reflects on-disk corruption.  syzbot triggered this condition using a malformed NTFS image. During a rename() operation involving a long filename (which spans multiple index entries), the empty bitmap allowed the name to be added without valid tracking. Subsequent deletion of the original entry failed with -ENOENT, due to unexpected index state.  Reject such cases by verifying that the bitmap is not empty when index blocks exist.
CVE-2025-40068: In the Linux kernel, the following vulnerability has been resolved:  fs: ntfs3: Fix integer overflow in run_unpack()  The MFT record relative to the file being opened contains its runlist, an array containing information about the file's location on the physical disk. Analysis of all Call Stack paths showed that the values of the runlist array, from which LCNs are calculated, are not validated before run_unpack function.  The run_unpack function decodes the compressed runlist data format from MFT attributes (for example, $DATA), converting them into a runs_tree structure, which describes the mapping of virtual clusters (VCN) to logical clusters (LCN). The NTFS3 subsystem also has a shortcut for deleting files from MFT records - in this case, the RUN_DEALLOCATE command is sent to the run_unpack input, and the function logic provides that all data transferred to the runlist about file or directory is deleted without creating a runs_tree structure.  Substituting the runlist in the $DATA attribute of the MFT record for an arbitrary file can lead either to access to arbitrary data on the disk bypassing access checks to them (since the inode access check occurs above) or to destruction of arbitrary data on the disk.  Add overflow check for addition operation.  Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-40069: In the Linux kernel, the following vulnerability has been resolved:  drm/msm: Fix obj leak in VM_BIND error path  If we fail a handle-lookup part way thru, we need to drop the already obtained obj references.  Patchwork: https://patchwork.freedesktop.org/patch/669784/