xamxte/cve-to-cwe huggingface dataset:
CVE-2025-68813: In the Linux kernel, the following vulnerability has been resolved:  ipvs: fix ipv4 null-ptr-deref in route error path  The IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure() without ensuring skb->dev is set, leading to a NULL pointer dereference in fib_compute_spec_dst() when ipv4_link_failure() attempts to send ICMP destination unreachable messages.  The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure") started calling __ip_options_compile() from ipv4_link_failure(). This code path eventually calls fib_compute_spec_dst() which dereferences skb->dev. An attempt was made to fix the NULL skb->dev dereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in ipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev) dereference by using a fallback device. The fix was incomplete because fib_compute_spec_dst() later in the call chain still accesses skb->dev directly, which remains NULL when IPVS calls dst_link_failure().  The crash occurs when: 1. IPVS processes a packet in NAT mode with a misconfigured destination 2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route 3. The error path calls dst_link_failure(skb) with skb->dev == NULL 4. ipv4_link_failure() → ipv4_send_dest_unreach() →    __ip_options_compile() → fib_compute_spec_dst() 5. fib_compute_spec_dst() dereferences NULL skb->dev  Apply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix ipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev before calling dst_link_failure().  KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f] CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2 RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233 RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285 Call Trace:   <TASK>   spec_dst_fill net/ipv4/ip_options.c:232   spec_dst_fill net/ipv4/ip_options.c:229   __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330   ipv4_send_dest_unreach net/ipv4/route.c:1252   ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265   dst_link_failure include/net/dst.h:437   __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412   ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764
CVE-2025-68814: In the Linux kernel, the following vulnerability has been resolved:  io_uring: fix filename leak in __io_openat_prep()   __io_openat_prep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak.  Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup.
CVE-2025-68815: In the Linux kernel, the following vulnerability has been resolved:  net/sched: ets: Remove drr class from the active list if it changes to strict  Whenever a user issues an ets qdisc change command, transforming a drr class into a strict one, the ets code isn't checking whether that class was in the active list and removing it. This means that, if a user changes a strict class (which was in the active list) back to a drr one, that class will be added twice to the active list [1].  Doing so with the following commands:  tc qdisc add dev lo root handle 1: ets bands 2 strict 1 tc qdisc add dev lo parent 1:2 handle 20: \     tbf rate 8bit burst 100b latency 1s tc filter add dev lo parent 1: basic classid 1:2 ping -c1 -W0.01 -s 56 127.0.0.1 tc qdisc change dev lo root handle 1: ets bands 2 strict 2 tc qdisc change dev lo root handle 1: ets bands 2 strict 1 ping -c1 -W0.01 -s 56 127.0.0.1  Will trigger the following splat with list debug turned on:  [   59.279014][  T365] ------------[ cut here ]------------ [   59.279452][  T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0. [   59.280153][  T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220 [   59.280860][  T365] Modules linked in: [   59.281165][  T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary) [   59.281977][  T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [   59.282391][  T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220 [   59.282842][  T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44 ... [   59.288812][  T365] Call Trace: [   59.289056][  T365]  <TASK> [   59.289224][  T365]  ? srso_alias_return_thunk+0x5/0xfbef5 [   59.289546][  T365]  ets_qdisc_change+0xd2b/0x1e80 [   59.289891][  T365]  ? __lock_acquire+0x7e7/0x1be0 [   59.290223][  T365]  ? __pfx_ets_qdisc_change+0x10/0x10 [   59.290546][  T365]  ? srso_alias_return_thunk+0x5/0xfbef5 [   59.290898][  T365]  ? __mutex_trylock_common+0xda/0x240 [   59.291228][  T365]  ? __pfx___mutex_trylock_common+0x10/0x10 [   59.291655][  T365]  ? srso_alias_return_thunk+0x5/0xfbef5 [   59.291993][  T365]  ? srso_alias_return_thunk+0x5/0xfbef5 [   59.292313][  T365]  ? trace_contention_end+0xc8/0x110 [   59.292656][  T365]  ? srso_alias_return_thunk+0x5/0xfbef5 [   59.293022][  T365]  ? srso_alias_return_thunk+0x5/0xfbef5 [   59.293351][  T365]  tc_modify_qdisc+0x63a/0x1cf0  Fix this by always checking and removing an ets class from the active list when changing it to strict.  [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663
CVE-2025-68816: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: fw_tracer, Validate format string parameters  Add validation for format string parameters in the firmware tracer to prevent potential security vulnerabilities and crashes from malformed format strings received from firmware.  The firmware tracer receives format strings from the device firmware and uses them to format trace messages. Without proper validation, bad firmware could provide format strings with invalid format specifiers (e.g., %s, %p, %n) that could lead to crashes, or other undefined behavior.  Add mlx5_tracer_validate_params() to validate that all format specifiers in trace strings are limited to safe integer/hex formats (%x, %d, %i, %u, %llx, %lx, etc.). Reject strings containing other format types that could be used to access arbitrary memory or cause crashes. Invalid format strings are added to the trace output for visibility with "BAD_FORMAT: " prefix.
CVE-2025-68819: In the Linux kernel, the following vulnerability has been resolved:  media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()  rlen value is a user-controlled value, but dtv5100_i2c_msg() does not check the size of the rlen value. Therefore, if it is set to a value larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.  Therefore, we need to add proper range checking to prevent this vuln.
CVE-2025-68820: In the Linux kernel, the following vulnerability has been resolved:  ext4: xattr: fix null pointer deref in ext4_raw_inode()  If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all() lacks error checking, this will lead to a null pointer dereference in ext4_raw_inode(), called right after ext4_get_inode_loc().  Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-68822: In the Linux kernel, the following vulnerability has been resolved:  Input: alps - fix use-after-free bugs caused by dev3_register_work  The dev3_register_work delayed work item is initialized within alps_reconnect() and scheduled upon receipt of the first bare PS/2 packet from an external PS/2 device connected to the ALPS touchpad. During device detachment, the original implementation calls flush_workqueue() in psmouse_disconnect() to ensure completion of dev3_register_work. However, the flush_workqueue() in psmouse_disconnect() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after flush_workqueue() has finished executing, the dev3_register_work could still be scheduled. Although the psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(), the scheduling of dev3_register_work remains unaffected.  The race condition can occur as follows:  CPU 0 (cleanup path)     | CPU 1 (delayed work) psmouse_disconnect()     |   psmouse_set_state()    |   flush_workqueue()      | alps_report_bare_ps2_packet()   alps_disconnect()      |   psmouse_queue_work()     kfree(priv); // FREE | alps_register_bare_ps2_mouse()                          |   priv = container_of(work...); // USE                          |   priv->dev3 // USE  Add disable_delayed_work_sync() in alps_disconnect() to ensure that dev3_register_work is properly canceled and prevented from executing after the alps_data structure has been deallocated.  This bug is identified by static analysis.
CVE-2025-71064: In the Linux kernel, the following vulnerability has been resolved:  net: hns3: using the num_tqps in the vf driver to apply for resources  Currently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqp is allocated using kinfo->num_tqps. However, kinfo->num_tqps is set to min(new_tqps, hdev->num_tqps);  Therefore, kinfo->num_tqps may be smaller than hdev->num_tqps, which causes some hdev->htqp[i] to remain uninitialized in hclgevf_knic_setup().  Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps, ensuring that the lengths of hdev->htqp and kinfo->tqp are consistent and that all elements are properly initialized.
CVE-2025-71068: In the Linux kernel, the following vulnerability has been resolved:  svcrdma: bound check rq_pages index in inline path  svc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without verifying rc_curpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.
CVE-2025-71071: In the Linux kernel, the following vulnerability has been resolved:  iommu/mediatek: fix use-after-free on probe deferral  The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers.  Fix this by keeping the references as expected while the iommu driver is bound.
CVE-2025-71073: In the Linux kernel, the following vulnerability has been resolved:  Input: lkkbd - disable pending work before freeing device  lkkbd_interrupt() schedules lk->tq via schedule_work(), and the work handler lkkbd_reinit() dereferences the lkkbd structure and its serio/input_dev fields.  lkkbd_disconnect() and error paths in lkkbd_connect() free the lkkbd structure without preventing the reinit work from being queued again until serio_close() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.  Use disable_work_sync() instead of cancel_work_sync() to ensure the reinit work cannot be re-queued, and call it both in lkkbd_disconnect() and in lkkbd_connect() error paths after serio_open().
CVE-2025-71074: In the Linux kernel, the following vulnerability has been resolved:  functionfs: fix the open/removal races  ffs_epfile_open() can race with removal, ending up with file->private_data pointing to freed object.  There is a total count of opened files on functionfs (both ep0 and dynamic ones) and when it hits zero, dynamic files get removed. Unfortunately, that removal can happen while another thread is in ffs_epfile_open(), but has not incremented the count yet. In that case open will succeed, leaving us with UAF on any subsequent read() or write().  The root cause is that ffs->opened is misused; atomic_dec_and_test() vs. atomic_add_return() is not a good idea, when object remains visible all along.  To untangle that  * serialize openers on ffs->mutex (both for ep0 and for dynamic files)  * have dynamic ones use atomic_inc_not_zero() and fail if we had zero ->opened; in that case the file we are opening is doomed.  * have the inodes of dynamic files marked on removal (from the callback of simple_recursive_removal()) - clear ->i_private there.  * have open of dynamic ones verify they hadn't been already removed, along with checking that state is FFS_ACTIVE.
CVE-2025-71075: In the Linux kernel, the following vulnerability has been resolved:  scsi: aic94xx: fix use-after-free in device removal path  The asd_pci_remove() function fails to synchronize with pending tasklets before freeing the asd_ha structure, leading to a potential use-after-free vulnerability.  When a device removal is triggered (via hot-unplug or module unload), race condition can occur.  The fix adds tasklet_kill() before freeing the asd_ha structure, ensuring all scheduled tasklets complete before cleanup proceeds.
CVE-2025-71076: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/oa: Limit num_syncs to prevent oversized allocations  The OA open parameters did not validate num_syncs, allowing userspace to pass arbitrarily large values, potentially leading to excessive allocations.  Add check to ensure that num_syncs does not exceed DRM_XE_MAX_SYNCS, returning -EINVAL when the limit is violated.  v2: use XE_IOCTL_DBG() and drop duplicated check. (Ashutosh)  (cherry picked from commit e057b2d2b8d815df3858a87dffafa2af37e5945b)
CVE-2025-71077: In the Linux kernel, the following vulnerability has been resolved:  tpm: Cap the number of PCR banks  tpm2_get_pcr_allocation() does not cap any upper limit for the number of banks. Cap the limit to eight banks so that out of bounds values coming from external I/O cause on only limited harm.
CVE-2025-71079: In the Linux kernel, the following vulnerability has been resolved:  net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write  A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex.  The problematic lock order is:  Thread A (rfkill_fop_write):   rfkill_fop_write()     mutex_lock(&rfkill_global_mutex)       rfkill_set_block()         nfc_rfkill_set_block()           nfc_dev_down()             device_lock(&dev->dev)    <- waits for device_lock  Thread B (nfc_unregister_device):   nfc_unregister_device()     device_lock(&dev->dev)       rfkill_unregister()         mutex_lock(&rfkill_global_mutex)  <- waits for rfkill_global_mutex  This creates a classic ABBA deadlock scenario.  Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock.  This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free.  The similar lock ordering in nfc_register_device() (device_lock -> rfkill_global_mutex via rfkill_register) is safe because during registration the device is not yet in rfkill_list, so no concurrent rfkill operations can occur on this device.
CVE-2025-71080: In the Linux kernel, the following vulnerability has been resolved:  ipv6: fix a BUG in rt6_get_pcpu_route() under PREEMPT_RT  On PREEMPT_RT kernels, after rt6_get_pcpu_route() returns NULL, the current task can be preempted. Another task running on the same CPU may then execute rt6_make_pcpu_route() and successfully install a pcpu_rt entry. When the first task resumes execution, its cmpxchg() in rt6_make_pcpu_route() will fail because rt6i_pcpu is no longer NULL, triggering the BUG_ON(prev). It's easy to reproduce it by adding mdelay() after rt6_get_pcpu_route().  Using preempt_disable/enable is not appropriate here because ip6_rt_pcpu_alloc() may sleep.  Fix this by handling the cmpxchg() failure gracefully on PREEMPT_RT: free our allocation and return the existing pcpu_rt installed by another task. The BUG_ON is replaced by WARN_ON_ONCE for non-PREEMPT_RT kernels where such races should not occur.
CVE-2025-71082: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: btusb: revert use of devm_kzalloc in btusb  This reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc in btusb.c file").  In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. This ties the lifetime of all the btusb data to the binding of a driver to one interface, INTF. In a driver that binds to other interfaces, ISOC and DIAG, this is an accident waiting to happen.  The issue is revealed in btusb_disconnect(), where calling usb_driver_release_interface(&btusb_driver, data->intf) will have devm free the data that is also being used by the other interfaces of the driver that may not be released yet.  To fix this, revert the use of devm and go back to freeing memory explicitly.
CVE-2025-71083: In the Linux kernel, the following vulnerability has been resolved:  drm/ttm: Avoid NULL pointer deref for evicted BOs  It is possible for a BO to exist that is not currently associated with a resource, e.g. because it has been evicted.  When devcoredump tries to read the contents of all BOs for dumping, we need to expect this as well -- in this case, ENODATA is recorded instead of the buffer contents.
CVE-2025-71084: In the Linux kernel, the following vulnerability has been resolved:  RDMA/cm: Fix leaking the multicast GID table reference  If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN:     GID entry ref leak for dev syz1 index 2 ref=573    WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]    WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886  Destroy the ah_attr after canceling the work, it is safe to call this twice.
CVE-2025-71086: In the Linux kernel, the following vulnerability has been resolved:  net: rose: fix invalid array index in rose_kill_by_device()  rose_kill_by_device() collects sockets into a local array[] and then iterates over them to disconnect sockets bound to a device being brought down.  The loop mistakenly indexes array[cnt] instead of array[i]. For cnt < ARRAY_SIZE(array), this reads an uninitialized entry; for cnt == ARRAY_SIZE(array), it is an out-of-bounds read. Either case can lead to an invalid socket pointer dereference and also leaks references taken via sock_hold().  Fix the index to use i.
CVE-2025-71087: In the Linux kernel, the following vulnerability has been resolved:  iavf: fix off-by-one issues in iavf_config_rss_reg()  There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.  Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were:     i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX which is safe since the value is the last valid index.  That commit changed the bounds to:     i <= adapter->rss_{key,lut}_size / 4 where `rss_{key,lut}_size / 4` is the number of dwords, so the last valid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=` accesses one element past the end.  Fix the issues by using `<` instead of `<=`, ensuring we do not exceed the bounds.  [1] KASAN splat about rss_key_size off-by-one   BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800   Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63    CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014   Workqueue: iavf iavf_watchdog_task   Call Trace:    <TASK>    dump_stack_lvl+0x6f/0xb0    print_report+0x170/0x4f3    kasan_report+0xe1/0x1a0    iavf_config_rss+0x619/0x800    iavf_watchdog_task+0x2be7/0x3230    process_one_work+0x7fd/0x1420    worker_thread+0x4d1/0xd40    kthread+0x344/0x660    ret_from_fork+0x249/0x320    ret_from_fork_asm+0x1a/0x30    </TASK>    Allocated by task 63:    kasan_save_stack+0x30/0x50    kasan_save_track+0x14/0x30    __kasan_kmalloc+0x7f/0x90    __kmalloc_noprof+0x246/0x6f0    iavf_watchdog_task+0x28fc/0x3230    process_one_work+0x7fd/0x1420    worker_thread+0x4d1/0xd40    kthread+0x344/0x660    ret_from_fork+0x249/0x320    ret_from_fork_asm+0x1a/0x30    The buggy address belongs to the object at ffff888102c50100    which belongs to the cache kmalloc-64 of size 64   The buggy address is located 0 bytes to the right of    allocated 52-byte region [ffff888102c50100, ffff888102c50134)    The buggy address belongs to the physical page:   page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50   flags: 0x200000000000000(node=0|zone=2)   page_type: f5(slab)   raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000   raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000   page dumped because: kasan: bad access detected    Memory state around the buggy address:    ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc    ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc   >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc                                        ^    ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc    ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc