xamxte/cve-to-cwe huggingface dataset:
CVE-2025-40270: In the Linux kernel, the following vulnerability has been resolved:  mm, swap: fix potential UAF issue for VMA readahead  Since commit 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning"), the common helper for allocating and preparing a folio in the swap cache layer no longer tries to get a swap device reference internally, because all callers of __read_swap_cache_async are already holding a swap entry reference.  The repeated swap device pinning isn't needed on the same swap device.  Caller of VMA readahead is also holding a reference to the target entry's swap device, but VMA readahead walks the page table, so it might encounter swap entries from other devices, and call __read_swap_cache_async on another device without holding a reference to it.  So it is possible to cause a UAF when swapoff of device A raced with swapin on device B, and VMA readahead tries to read swap entries from device A.  It's not easy to trigger, but in theory, it could cause real issues.  Make VMA readahead try to get the device reference first if the swap device is a different one from the target entry.
CVE-2025-40271: In the Linux kernel, the following vulnerability has been resolved:  fs/proc: fix uaf in proc_readdir_de()  Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access.  We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.  We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time.  The steps of the issue is as follows:  1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current    pde is tun3;  2) in the [time windows] unregister netdevice tun3 and tun2, and erase    them from rbtree.  erase tun3 first, and then erase tun2.  the    pde(tun2) will be released to slab;  3) continue to getdent process, then pde_subdir_next() will return    pde(tun2) which is released, it will case uaf access.  CPU 0                                      |    CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/      |   unregister_netdevice(tun->dev)   //tun3 tun2 sys_getdents64()                           |   iterate_dir()                            |     proc_readdir()                         |       proc_readdir_de()                    |     snmp6_unregister_dev()         pde_get(de);                       |       proc_remove()         read_unlock(&proc_subdir_lock);    |         remove_proc_subtree()                                            |           write_lock(&proc_subdir_lock);         [time window]                      |           rb_erase(&root->subdir_node, &parent->subdir);                                            |           write_unlock(&proc_subdir_lock);         read_lock(&proc_subdir_lock);      |         next = pde_subdir_next(de);        |         pde_put(de);                       |         de = next;    //UAF                |  rbtree of dev_snmp6                         |                     pde(tun3)                      /    \                   NULL  pde(tun2)
CVE-2025-40272: In the Linux kernel, the following vulnerability has been resolved:  mm/secretmem: fix use-after-free race in fault handler  When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping.  If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping.  The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map.  However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping.  If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault.  Fix the ordering to restore the direct map before the folio is freed.
CVE-2025-40275: In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd  In snd_usb_create_streams(), for UAC version 3 devices, the Interface Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this call fails, a fallback routine attempts to obtain the IAD from the next interface and sets a BADD profile. However, snd_usb_mixer_controls_badd() assumes that the IAD retrieved from usb_ifnum_to_if() is always valid, without performing a NULL check. This can lead to a NULL pointer dereference when usb_ifnum_to_if() fails to find the interface descriptor.  This patch adds a NULL pointer check after calling usb_ifnum_to_if() in snd_usb_mixer_controls_badd() to prevent the dereference.  This issue was discovered by syzkaller, which triggered the bug by sending a crafted USB device descriptor.
CVE-2025-40277: In the Linux kernel, the following vulnerability has been resolved:  drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE  This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.
CVE-2025-40278: In the Linux kernel, the following vulnerability has been resolved:  net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak  Fix a KMSAN kernel-infoleak detected  by the syzbot .  [net?] KMSAN: kernel-infoleak in __skb_datagram_iter  In tcf_ife_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace.  Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied.  This change silences the KMSAN report and prevents potential information leaks from the kernel memory.  This fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures no infoleak.
CVE-2025-40279: In the Linux kernel, the following vulnerability has been resolved:  net: sched: act_connmark: initialize struct tc_ife to fix kernel leak  In tcf_connmark_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace.  Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied.
CVE-2025-40281: In the Linux kernel, the following vulnerability has been resolved:  sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto  syzbot reported a possible shift-out-of-bounds [1]  Blamed commit added rto_alpha_max and rto_beta_max set to 1000.  It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta.  In order to prevent user regression, perform the test at run time.  Also add READ_ONCE() annotations as sysctl values can change under us.  [1]  UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace:  <TASK>   __dump_stack lib/dump_stack.c:94 [inline]   dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120   ubsan_epilogue lib/ubsan.c:233 [inline]   __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494   sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509   sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502   sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338   sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline]   sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]
CVE-2025-40283: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF  There is a KASAN: slab-use-after-free read in btusb_disconnect(). Calling "usb_driver_release_interface(&btusb_driver, data->intf)" will free the btusb data associated with the interface. The same data is then used later in the function, hence the UAF.  Fix by moving the accesses to btusb data to before the data is free'd.
CVE-2025-40284: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: MGMT: cancel mesh send timer when hdev removed  mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone.  Cancel the timer when MGMT removes the hdev, like other MGMT timers.  Should fix the BUG: sporadically seen by BlueZ test bot (in "Mesh - Send cancel - 1" test).  Log: ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  __kasan_save_free_info+0x3a/0x60  __kasan_slab_free+0x43/0x70  kfree+0x103/0x500  device_release+0x9a/0x210  kobject_put+0x100/0x1e0  vhci_release+0x18b/0x240 ------
CVE-2025-40285: In the Linux kernel, the following vulnerability has been resolved:  smb/server: fix possible refcount leak in smb2_sess_setup()  Reference count of ksmbd_session will leak when session need reconnect. Fix this by adding the missing ksmbd_user_session_put().
CVE-2025-40286: In the Linux kernel, the following vulnerability has been resolved:  smb/server: fix possible memory leak in smb2_read()  Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree().
CVE-2025-40287: In the Linux kernel, the following vulnerability has been resolved:  exfat: fix improper check of dentry.stream.valid_size  We found an infinite loop bug in the exFAT file system that can lead to a Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is malformed, the following system calls — SYS_openat, SYS_ftruncate, and SYS_pwrite64 — can cause the kernel to hang.  Root cause analysis shows that the size validation code in exfat_find() does not check whether dentry.stream.valid_size is negative. As a result, the system calls mentioned above can succeed and eventually trigger the DoS issue.  This patch adds a check for negative dentry.stream.valid_size to prevent this vulnerability.
CVE-2025-40288: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices  Previously, APU platforms (and other scenarios with uninitialized VRAM managers) triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL, but that `man->bdev` (the backing device pointer within the manager) remains uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to a kernel OOPS.  1. **amdgpu_cs.c**: Extend the existing bandwidth control check in    `amdgpu_cs_get_threshold_for_moves()` to include a check for    `ttm_resource_manager_used()`. If the manager is not used (uninitialized    `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific    logic that would trigger the NULL dereference.  2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info    reporting to use a conditional: if the manager is used, return the real VRAM    usage; otherwise, return 0. This avoids accessing `man->bdev` when it is    NULL.  3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function)    data write path. Use `ttm_resource_manager_used()` to check validity: if the    manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set    `fb_usage` to 0 (APUs have no discrete framebuffer to report).  This approach is more robust than APU-specific checks because it: - Works for all scenarios where the VRAM manager is uninitialized (not just APUs), - Aligns with TTM's design by using its native helper function, - Preserves correct behavior for discrete GPUs (which have fully initialized   `man->bdev` and pass the `ttm_resource_manager_used()` check).  v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)
CVE-2025-40290: In the Linux kernel, the following vulnerability has been resolved:  xsk: avoid data corruption on cq descriptor number  Since commit 30f241fcf52a ("xsk: Fix immature cq descriptor production"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue.  skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference.   BUG: kernel NULL pointer dereference, address: 0000000000000000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 0 P4D 0  Oops: Oops: 0000 [#1] SMP NOPTI  CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy)  Debian 6.16.12-1  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014  RIP: 0010:xsk_destruct_skb+0xd0/0x180  [...]  Call Trace:   <IRQ>   ? napi_complete_done+0x7a/0x1a0   ip_rcv_core+0x1bb/0x340   ip_rcv+0x30/0x1f0   __netif_receive_skb_one_core+0x85/0xa0   process_backlog+0x87/0x130   __napi_poll+0x28/0x180   net_rx_action+0x339/0x420   handle_softirqs+0xdc/0x320   ? handle_edge_irq+0x90/0x1e0   do_softirq.part.0+0x3b/0x60   </IRQ>   <TASK>   __local_bh_enable_ip+0x60/0x70   __dev_direct_xmit+0x14e/0x1f0   __xsk_generic_xmit+0x482/0xb70   ? __remove_hrtimer+0x41/0xa0   ? __xsk_generic_xmit+0x51/0xb70   ? _raw_spin_unlock_irqrestore+0xe/0x40   xsk_sendmsg+0xda/0x1c0   __sys_sendto+0x1ee/0x200   __x64_sys_sendto+0x24/0x30   do_syscall_64+0x84/0x2f0   ? __pfx_pollwake+0x10/0x10   ? __rseq_handle_notify_resume+0xad/0x4c0   ? restore_fpregs_from_fpstate+0x3c/0x90   ? switch_fpu_return+0x5b/0xe0   ? do_syscall_64+0x204/0x2f0   ? do_syscall_64+0x204/0x2f0   ? do_syscall_64+0x204/0x2f0   entry_SYSCALL_64_after_hwframe+0x76/0x7e   </TASK>  [...]  Kernel panic - not syncing: Fatal exception in interrupt  Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)  Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.
CVE-2025-40291: In the Linux kernel, the following vulnerability has been resolved:  io_uring: fix regbuf vector size truncation  There is a report of io_estimate_bvec_size() truncating the calculated number of segments that leads to corruption issues. Check it doesn't overflow "int"s used later. Rough but simple, can be improved on top.
CVE-2025-40292: In the Linux kernel, the following vulnerability has been resolved:  virtio-net: fix received length check in big packets  Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags.  Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one.  This commit fixes the received length check corresponding to the new change.
CVE-2025-40293: In the Linux kernel, the following vulnerability has been resolved:  iommufd: Don't overflow during division for dirty tracking  If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow to 0 and this triggers divide by 0.  In this case the index should just be 0, so reorganize things to divide by shift and avoid hitting any overflows.
CVE-2025-40294: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()  In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied.  Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH.  Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-40296: In the Linux kernel, the following vulnerability has been resolved:  platform/x86: int3472: Fix double free of GPIO device during unregister  regulator_unregister() already frees the associated GPIO device. On ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to random failures when other drivers (typically Intel THC) attempt to allocate interrupts. The root cause is that the reference count of the pinctrl_intel_platform module unexpectedly drops to zero when this driver defers its probe.  This behavior can also be reproduced by unloading the module directly.  Fix the issue by removing the redundant release of the GPIO device during regulator unregistration.
CVE-2025-40297: In the Linux kernel, the following vulnerability has been resolved:  net: bridge: fix use-after-free due to MST port state bypass  syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot.  [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be
CVE-2025-40298: In the Linux kernel, the following vulnerability has been resolved:  gve: Implement settime64 with -EOPNOTSUPP  ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference.
CVE-2025-40299: In the Linux kernel, the following vulnerability has been resolved:  gve: Implement gettimex64 with -EOPNOTSUPP  gve implemented a ptp_clock for sole use of do_aux_work at this time. ptp_clock_gettime() and ptp_sys_offset() assume every ptp_clock has implemented either gettimex64 or gettime64. Stub gettimex64 and return -EOPNOTSUPP to prevent NULL dereferencing.
CVE-2025-40301: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_event: validate skb length for unknown CC opcode  In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory.  The fix is to check skb->len before using skb->data.
CVE-2025-40303: In the Linux kernel, the following vulnerability has been resolved:  btrfs: ensure no dirty metadata is written back for an fs with errors  [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers().  It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free.  [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state.  But there are some metadata modifications before that error, and they are still in the btree inode page cache.  Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty.  And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata.  And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free.  [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them.  Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues.  The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs.
CVE-2025-40304: In the Linux kernel, the following vulnerability has been resolved:  fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds  Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches.  Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.