xamxte/cve-to-cwe huggingface dataset:
CVE-2025-68249: In the Linux kernel, the following vulnerability has been resolved:  most: usb: hdm_probe: Fix calling put_device() before device initialization  The early error path in hdm_probe() can jump to err_free_mdev before &mdev->dev has been initialized with device_initialize(). Calling put_device(&mdev->dev) there triggers a device core WARN and ends up invoking kref_put(&kobj->kref, kobject_release) on an uninitialized kobject.  In this path the private struct was only kmalloc'ed and the intended release is effectively kfree(mdev) anyway, so free it directly instead of calling put_device() on an uninitialized device.  This removes the WARNING and fixes the pre-initialization error path.
CVE-2025-68251: In the Linux kernel, the following vulnerability has been resolved:  erofs: avoid infinite loops due to corrupted subpage compact indexes  Robert reported an infinite loop observed by two crafted images.  The root cause is that `clusterofs` can be larger than `lclustersize` for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:    blocksize = lclustersize = 512   lcn = 6   clusterofs = 515  Move the corresponding check for full compress indexes to `z_erofs_load_lcluster_from_disk()` to also cover subpage compact compress indexes.  It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX` check, since it should be placed right after `z_erofs_load_{compact,full}_lcluster()`.
CVE-2025-68252: In the Linux kernel, the following vulnerability has been resolved:  misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup  In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to the dma_buf for comparison purposes. However, this reference is never released when the function returns, leading to a dma_buf memory leak.  Fix this by adding dma_buf_put before returning from the function, ensuring that the temporarily acquired reference is properly released regardless of whether a matching map is found.  Rule: add
CVE-2025-68254: In the Linux kernel, the following vulnerability has been resolved:  staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing  The Extended Supported Rates (ESR) IE handling in OnBeacon accessed *(p + 1 + ielen) and *(p + 2 + ielen) without verifying that these offsets lie within the received frame buffer. A malformed beacon with an ESR IE positioned at the end of the buffer could cause an out-of-bounds read, potentially triggering a kernel panic.  Add a boundary check to ensure that the ESR IE body and the subsequent bytes are within the limits of the frame before attempting to access them.  This prevents OOB reads caused by malformed beacon frames.
CVE-2025-68255: In the Linux kernel, the following vulnerability has been resolved:  staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing  The Supported Rates IE length from an incoming Association Request frame was used directly as the memcpy() length when copying into a fixed-size 16-byte stack buffer (supportRate). A malicious station can advertise an IE length larger than 16 bytes, causing a stack buffer overflow.  Clamp ie_len to the buffer size before copying the Supported Rates IE, and correct the bounds check when merging Extended Supported Rates to prevent a second potential overflow.  This prevents kernel stack corruption triggered by malformed association requests.
CVE-2025-68256: In the Linux kernel, the following vulnerability has been resolved:  staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser  The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop.  Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element.  This prevents OOB reads and ensures the parser terminates safely on malformed frames.
CVE-2025-68258: In the Linux kernel, the following vulnerability has been resolved:  comedi: multiq3: sanitize config options in multiq3_attach()  Syzbot identified an issue [1] in multiq3_attach() that induces a task timeout due to open() or COMEDI_DEVCONFIG ioctl operations, specifically, in the case of multiq3 driver.  This problem arose when syzkaller managed to craft weird configuration options used to specify the number of channels in encoder subdevice. If a particularly great number is passed to s->n_chan in multiq3_attach() via it->options[2], then multiple calls to multiq3_encoder_reset() at the end of driver-specific attach() method will be running for minutes, thus blocking tasks and affected devices as well.  While this issue is most likely not too dangerous for real-life devices, it still makes sense to sanitize configuration inputs. Enable a sensible limit on the number of encoder chips (4 chips max, each with 2 channels) to stop this behaviour from manifesting.  [1] Syzbot crash: INFO: task syz.2.19:6067 blocked for more than 143 seconds. ... Call Trace:  <TASK>  context_switch kernel/sched/core.c:5254 [inline]  __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862  __schedule_loop kernel/sched/core.c:6944 [inline]  schedule+0x165/0x360 kernel/sched/core.c:6959  schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016  __mutex_lock_common kernel/locking/mutex.c:676 [inline]  __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760  comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868  chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414  do_dentry_open+0x953/0x13f0 fs/open.c:965  vfs_open+0x3b/0x340 fs/open.c:1097 ...
CVE-2025-68259: In the Linux kernel, the following vulnerability has been resolved:  KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced  When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn instruction, discard the exception and retry the instruction if the code stream is changed (e.g. by a different vCPU) between when the CPU executes the instruction and when KVM decodes the instruction to get the next RIP.  As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction"), failure to verify that the correct INTn instruction was decoded can effectively clobber guest state due to decoding the wrong instruction and thus specifying the wrong next RIP.  The bug most often manifests as "Oops: int3" panics on static branch checks in Linux guests.  Enabling or disabling a static branch in Linux uses the kernel's "text poke" code patching mechanism.  To modify code while other CPUs may be executing that code, Linux (temporarily) replaces the first byte of the original instruction with an int3 (opcode 0xcc), then patches in the new code stream except for the first byte, and finally replaces the int3 with the first byte of the new code stream.  If a CPU hits the int3, i.e. executes the code while it's being modified, then the guest kernel must look up the RIP to determine how to handle the #BP, e.g. by emulating the new instruction.  If the RIP is incorrect, then this lookup fails and the guest kernel panics.  The bug reproduces almost instantly by hacking the guest kernel to repeatedly check a static branch[1] while running a drgn script[2] on the host to constantly swap out the memory containing the guest's TSS.  [1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a [2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b
CVE-2025-68261: In the Linux kernel, the following vulnerability has been resolved:  ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()  Fix a race between inline data destruction and block mapping.  The function ext4_destroy_inline_data_nolock() changes the inode data layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS. At the same time, another thread may execute ext4_map_blocks(), which tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks() or ext4_ind_map_blocks().  Without i_data_sem protection, ext4_ind_map_blocks() may receive inode with EXT4_INODE_EXTENTS flag and triggering assert.  kernel BUG at fs/ext4/indirect.c:546! EXT4-fs (loop2): unmounting filesystem. invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546  Call Trace:  <TASK>  ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681  _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822  ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124  ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255  ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000  generic_perform_write+0x259/0x5d0 mm/filemap.c:3846  ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285  ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679  call_write_iter include/linux/fs.h:2271 [inline]  do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735  do_iter_write+0x186/0x710 fs/read_write.c:861  vfs_iter_write+0x70/0xa0 fs/read_write.c:902  iter_file_splice_write+0x73b/0xc90 fs/splice.c:685  do_splice_from fs/splice.c:763 [inline]  direct_splice_actor+0x10f/0x170 fs/splice.c:950  splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896  do_splice_direct+0x1a9/0x280 fs/splice.c:1002  do_sendfile+0xb13/0x12c0 fs/read_write.c:1255  __do_sys_sendfile64 fs/read_write.c:1323 [inline]  __se_sys_sendfile64 fs/read_write.c:1309 [inline]  __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309  do_syscall_x64 arch/x86/entry/common.c:51 [inline]  do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
CVE-2025-68262: In the Linux kernel, the following vulnerability has been resolved:  crypto: zstd - fix double-free in per-CPU stream cleanup  The crypto/zstd module has a double-free bug that occurs when multiple tfms are allocated and freed.  The issue happens because zstd_streams (per-CPU contexts) are freed in zstd_exit() during every tfm destruction, rather than being managed at the module level.  When multiple tfms exist, each tfm exit attempts to free the same shared per-CPU streams, resulting in a double-free.  This leads to a stack trace similar to:    BUG: Bad page state in process kworker/u16:1  pfn:106fd93   page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x106fd93   flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)   page_type: 0xffffffff()   raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000   raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000   page dumped because: nonzero entire_mapcount   Modules linked in: ...   CPU: 3 UID: 0 PID: 2506 Comm: kworker/u16:1 Kdump: loaded Tainted: G    B   Hardware name: ...   Workqueue: btrfs-delalloc btrfs_work_helper   Call Trace:    <TASK>    dump_stack_lvl+0x5d/0x80    bad_page+0x71/0xd0    free_unref_page_prepare+0x24e/0x490    free_unref_page+0x60/0x170    crypto_acomp_free_streams+0x5d/0xc0    crypto_acomp_exit_tfm+0x23/0x50    crypto_destroy_tfm+0x60/0xc0    ...  Change the lifecycle management of zstd_streams to free the streams only once during module cleanup.
CVE-2025-68263: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: ipc: fix use-after-free in ipc_msg_send_request  ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. The generic netlink handler (handle_generic_event()/handle_response()) fills entry->response under ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free entry->response without holding the same lock.  Under high concurrency this allows a race where handle_response() is copying data into entry->response while ipc_msg_send_request() has just freed it, leading to a slab-use-after-free reported by KASAN in handle_generic_event():    BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd]   Write of size 12 at addr ffff888198ee6e20 by task pool/109349   ...   Freed by task:     kvfree     ipc_msg_send_request [ksmbd]     ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd]  Fix by: - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating   entry->response, freeing it when invalid, and removing the entry from   ipc_msg_table. - Returning the final entry->response pointer to the caller only after   the hash entry is removed under the lock. - Returning NULL in the error path, preserving the original API   semantics.  This makes all accesses to entry->response consistent with handle_response(), which already updates and fills the response buffer under ipc_msg_table_lock, and closes the race that allowed the UAF.
CVE-2025-68264: In the Linux kernel, the following vulnerability has been resolved:  ext4: refresh inline data size before write operations  The cached ei->i_inline_size can become stale between the initial size check and when ext4_update_inline_data()/ext4_create_inline_data() use it. Although ext4_get_max_inline_size() reads the correct value at the time of the check, concurrent xattr operations can modify i_inline_size before ext4_write_lock_xattr() is acquired.  This causes ext4_update_inline_data() and ext4_create_inline_data() to work with stale capacity values, leading to a BUG_ON() crash in ext4_write_inline_data():    kernel BUG at fs/ext4/inline.c:1331!   BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);  The race window: 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, i_inline_size changes to 40] 4. ext4_write_lock_xattr() acquires lock 5. ext4_update_inline_data() uses stale i_inline_size = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers  Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock() immediately after acquiring xattr_sem. This ensures ext4_update_inline_data() and ext4_create_inline_data() work with current values that are protected from concurrent modifications.  This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inline_data file while its xattrs are changing") which fixed i_inline_off staleness. This patch addresses the related i_inline_size staleness issue.
CVE-2025-68265: In the Linux kernel, the following vulnerability has been resolved:  nvme: fix admin request_queue lifetime  The namespaces can access the controller's admin request_queue, and stale references on the namespaces may exist after tearing down the controller. Ensure the admin request_queue is active by moving the controller's 'put' to after all controller references have been released to ensure no one is can access the request_queue. This fixes a reported use-after-free bug:    BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0   Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287   CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G            E       6.13.2-ga1582f1a031e #15   Tainted: [E]=UNSIGNED_MODULE   Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025   Call Trace:    <TASK>    dump_stack_lvl+0x4f/0x60    print_report+0xc4/0x620    ? _raw_spin_lock_irqsave+0x70/0xb0    ? _raw_read_unlock_irqrestore+0x30/0x30    ? blk_queue_enter+0x41c/0x4a0    kasan_report+0xab/0xe0    ? blk_queue_enter+0x41c/0x4a0    blk_queue_enter+0x41c/0x4a0    ? __irq_work_queue_local+0x75/0x1d0    ? blk_queue_start_drain+0x70/0x70    ? irq_work_queue+0x18/0x20    ? vprintk_emit.part.0+0x1cc/0x350    ? wake_up_klogd_work_func+0x60/0x60    blk_mq_alloc_request+0x2b7/0x6b0    ? __blk_mq_alloc_requests+0x1060/0x1060    ? __switch_to+0x5b7/0x1060    nvme_submit_user_cmd+0xa9/0x330    nvme_user_cmd.isra.0+0x240/0x3f0    ? force_sigsegv+0xe0/0xe0    ? nvme_user_cmd64+0x400/0x400    ? vfs_fileattr_set+0x9b0/0x9b0    ? cgroup_update_frozen_flag+0x24/0x1c0    ? cgroup_leave_frozen+0x204/0x330    ? nvme_ioctl+0x7c/0x2c0    blkdev_ioctl+0x1a8/0x4d0    ? blkdev_common_ioctl+0x1930/0x1930    ? fdget+0x54/0x380    __x64_sys_ioctl+0x129/0x190    do_syscall_64+0x5b/0x160    entry_SYSCALL_64_after_hwframe+0x4b/0x53   RIP: 0033:0x7f765f703b0b   Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48   RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010   RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b   RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003   RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000   R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003   R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60    </TASK>
CVE-2025-68266: In the Linux kernel, the following vulnerability has been resolved:  bfs: Reconstruct file type when loading from disk  syzbot is reporting that S_IFMT bits of inode->i_mode can become bogus when the S_IFMT bits of the 32bits "mode" field loaded from disk are corrupted or when the 32bits "attributes" field loaded from disk are corrupted.  A documentation says that BFS uses only lower 9 bits of the "mode" field. But I can't find an explicit explanation that the unused upper 23 bits (especially, the S_IFMT bits) are initialized with 0.  Therefore, ignore the S_IFMT bits of the "mode" field loaded from disk. Also, verify that the value of the "attributes" field loaded from disk is either BFS_VREG or BFS_VDIR (because BFS supports only regular files and the root directory).
CVE-2025-68281: In the Linux kernel, the following vulnerability has been resolved:  ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list  "struct sdca_control" declares "values" field as integer array. But the memory allocated to it is of char array. This causes crash for sdca_parse_function API. This patch addresses the issue by allocating correct data size.
CVE-2025-68282: In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: udc: fix use-after-free in usb_gadget_state_work  A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN:    BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0   Workqueue: events usb_gadget_state_work  The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget().  Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after device removal") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free.  This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.
CVE-2025-68283: In the Linux kernel, the following vulnerability has been resolved:  libceph: replace BUG_ON with bounds check for map->max_osd  OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd.  [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic   edits ]
CVE-2025-68284: In the Linux kernel, the following vulnerability has been resolved:  libceph: prevent potential out-of-bounds writes in handle_auth_session_key()  The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets.  [ idryomov: changelog ]
CVE-2025-68285: In the Linux kernel, the following vulnerability has been resolved:  libceph: fix potential use-after-free in have_mon_and_osd_map()  The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received.  Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one      kfree(monc->monmap);     monc->monmap = monmap;      ceph_osdmap_destroy(osdc->osdmap);     osdc->osdmap = newmap;  under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in      client->monc.monmap && client->monc.monmap->epoch &&         client->osdc.osdmap && client->osdc.osdmap->epoch;  condition to dereference an already freed map.  This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:      BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70     Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305     CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266     ...     Call Trace:     <TASK>     have_mon_and_osd_map+0x56/0x70     ceph_open_session+0x182/0x290     ceph_get_tree+0x333/0x680     vfs_get_tree+0x49/0x180     do_new_mount+0x1a3/0x2d0     path_mount+0x6dd/0x730     do_mount+0x99/0xe0     __do_sys_mount+0x141/0x180     do_syscall_64+0x9f/0x100     entry_SYSCALL_64_after_hwframe+0x76/0x7e     </TASK>      Allocated by task 13305:     ceph_osdmap_alloc+0x16/0x130     ceph_osdc_init+0x27a/0x4c0     ceph_create_client+0x153/0x190     create_fs_client+0x50/0x2a0     ceph_get_tree+0xff/0x680     vfs_get_tree+0x49/0x180     do_new_mount+0x1a3/0x2d0     path_mount+0x6dd/0x730     do_mount+0x99/0xe0     __do_sys_mount+0x141/0x180     do_syscall_64+0x9f/0x100     entry_SYSCALL_64_after_hwframe+0x76/0x7e      Freed by task 9475:     kfree+0x212/0x290     handle_one_map+0x23c/0x3b0     ceph_osdc_handle_map+0x3c9/0x590     mon_dispatch+0x655/0x6f0     ceph_con_process_message+0xc3/0xe0     ceph_con_v1_try_read+0x614/0x760     ceph_con_workfn+0x2de/0x650     process_one_work+0x486/0x7c0     process_scheduled_works+0x73/0x90     worker_thread+0x1c8/0x2a0     kthread+0x2ec/0x300     ret_from_fork+0x24/0x40     ret_from_fork_asm+0x1a/0x30  Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate.  While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth().  monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.