xamxte/cve-to-cwe huggingface dataset:
CVE-2026-23183: In the Linux kernel, the following vulnerability has been resolved:  cgroup/dmem: fix NULL pointer dereference when setting max  An issue was triggered:   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: 15 UID: 0 PID: 658 Comm: bash Tainted: 6.19.0-rc6-next-2026012  Tainted: [O]=OOT_MODULE  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),  RIP: 0010:strcmp+0x10/0x30  RSP: 0018:ffffc900017f7dc0 EFLAGS: 00000246  RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888107cd4358  RDX: 0000000019f73907 RSI: ffffffff82cc381a RDI: 0000000000000000  RBP: ffff8881016bef0d R08: 000000006c0e7145 R09: 0000000056c0e714  R10: 0000000000000001 R11: ffff888107cd4358 R12: 0007ffffffffffff  R13: ffff888101399200 R14: ffff888100fcb360 R15: 0007ffffffffffff  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000000000000000 CR3: 0000000105c79000 CR4: 00000000000006f0  Call Trace:   <TASK>   dmemcg_limit_write.constprop.0+0x16d/0x390   ? __pfx_set_resource_max+0x10/0x10   kernfs_fop_write_iter+0x14e/0x200   vfs_write+0x367/0x510   ksys_write+0x66/0xe0   do_syscall_64+0x6b/0x390   entry_SYSCALL_64_after_hwframe+0x76/0x7e  RIP: 0033:0x7f42697e1887  It was trriggered setting max without limitation, the command is like: "echo test/region0 > dmem.max". To fix this issue, add check whether options is valid after parsing the region_name.
CVE-2026-23184: In the Linux kernel, the following vulnerability has been resolved:  binder: fix UAF in binder_netlink_report()  Oneway transactions sent to frozen targets via binder_proc_transaction() return a BR_TRANSACTION_PENDING_FROZEN error but they are still treated as successful since the target is expected to thaw at some point. It is then not safe to access 't' after BR_TRANSACTION_PENDING_FROZEN errors as the transaction could have been consumed by the now thawed target.  This is the case for binder_netlink_report() which derreferences 't' after a pending frozen error, as pointed out by the following KASAN report:    ==================================================================   BUG: KASAN: slab-use-after-free in binder_netlink_report.isra.0+0x694/0x6c8   Read of size 8 at addr ffff00000f98ba38 by task binder-util/522    CPU: 4 UID: 0 PID: 522 Comm: binder-util Not tainted 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT   Hardware name: linux,dummy-virt (DT)   Call trace:    binder_netlink_report.isra.0+0x694/0x6c8    binder_transaction+0x66e4/0x79b8    binder_thread_write+0xab4/0x4440    binder_ioctl+0x1fd4/0x2940    [...]    Allocated by task 522:    __kmalloc_cache_noprof+0x17c/0x50c    binder_transaction+0x584/0x79b8    binder_thread_write+0xab4/0x4440    binder_ioctl+0x1fd4/0x2940    [...]    Freed by task 488:    kfree+0x1d0/0x420    binder_free_transaction+0x150/0x234    binder_thread_read+0x2d08/0x3ce4    binder_ioctl+0x488/0x2940    [...]   ==================================================================  Instead, make a transaction copy so the data can be safely accessed by binder_netlink_report() after a pending frozen error. While here, add a comment about not using t->buffer in binder_netlink_report().
CVE-2026-23185: In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mld: cancel mlo_scan_start_wk  mlo_scan_start_wk is not canceled on disconnection. In fact, it is not canceled anywhere except in the restart cleanup, where we don't really have to.  This can cause an init-after-queue issue: if, for example, the work was queued and then drv_change_interface got executed.  This can also cause use-after-free: if the work is executed after the vif is freed.
CVE-2026-23186: In the Linux kernel, the following vulnerability has been resolved:  hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()  The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal.  Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time.  To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify().  For simplicity, it is a static mutex which should not be a problem from the performance perspective.  The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered.  The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them.  In addition, notice that hwmon_device_register_with_info() may fail in which case resource->hwmon_dev will become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case to acpi_power_meter_notify() and acpi_power_meter_remove().
CVE-2026-23188: In the Linux kernel, the following vulnerability has been resolved:  net: usb: r8152: fix resume reset deadlock  rtl8152 can trigger device reset during reset which potentially can result in a deadlock:   **** DPM device timeout after 10 seconds; 15 seconds until panic ****  Call Trace:  <TASK>  schedule+0x483/0x1370  schedule_preempt_disabled+0x15/0x30  __mutex_lock_common+0x1fd/0x470  __rtl8152_set_mac_address+0x80/0x1f0  dev_set_mac_address+0x7f/0x150  rtl8152_post_reset+0x72/0x150  usb_reset_device+0x1d0/0x220  rtl8152_resume+0x99/0xc0  usb_resume_interface+0x3e/0xc0  usb_resume_both+0x104/0x150  usb_resume+0x22/0x110  The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again.  Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutex_lock() deadlock.
CVE-2026-23189: In the Linux kernel, the following vulnerability has been resolved:  ceph: fix NULL pointer dereference in ceph_mds_auth_match()  The CephFS kernel client has regression starting from 6.18-rc1. We have issue in ceph_mds_auth_match() if fs_name == NULL:      const char fs_name = mdsc->fsc->mount_options->mds_namespace;     ...     if (auth->match.fs_name && strcmp(auth->match.fs_name, fs_name)) {             / fsname mismatch, try next one */             return 0;     }  Patrick Donnelly suggested that: In summary, we should definitely start decoding `fs_name` from the MDSMap and do strict authorizations checks against it. Note that the `-o mds_namespace=foo` should only be used for selecting the file system to mount and nothing else. It's possible no mds_namespace is specified but the kernel will mount the only file system that exists which may have name "foo".  This patch reworks ceph_mdsmap_decode() and namespace_equals() with the goal of supporting the suggested concept. Now struct ceph_mdsmap contains m_fs_name field that receives copy of extracted FS name by ceph_extract_encoded_string(). For the case of "old" CephFS file systems, it is used "cephfs" name.  [ idryomov: replace redundant %*pE with %s in ceph_mdsmap_decode(),   get rid of a series of strlen() calls in ceph_namespace_match(),   drop changes to namespace_equals() body to avoid treating empty   mds_namespace as equal, drop changes to ceph_mdsc_handle_fsmap()   as namespace_equals() isn't an equivalent substitution there ]
CVE-2026-23190: In the Linux kernel, the following vulnerability has been resolved:  ASoC: amd: fix memory leak in acp3x pdm dma ops
CVE-2026-23191: In the Linux kernel, the following vulnerability has been resolved:  ALSA: aloop: Fix racy access at PCM trigger  The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers.  For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with   cable->lock spinlock, and add the proper NULL checks.  This avoids   already some racy accesses. - In addition, now we try to check the state of the capture PCM stream   that may be stopped in this function, which was the major pain point   leading to UAF.
CVE-2026-23192: In the Linux kernel, the following vulnerability has been resolved:  linkwatch: use __dev_put() in callers to prevent UAF  After linkwatch_do_dev() calls __dev_put() to release the linkwatch reference, the device refcount may drop to 1. At this point, netdev_run_todo() can proceed (since linkwatch_sync_dev() sees an empty list and returns without blocking), wait for the refcount to become 1 via netdev_wait_allrefs_any(), and then free the device via kobject_put().  This creates a use-after-free when __linkwatch_run_queue() tries to call netdev_unlock_ops() on the already-freed device.  Note that adding netdev_lock_ops()/netdev_unlock_ops() pair in netdev_run_todo() before kobject_put() would not work, because netdev_lock_ops() is conditional - it only locks when netdev_need_ops_lock() returns true. If the device doesn't require ops_lock, linkwatch won't hold any lock, and netdev_run_todo() acquiring the lock won't provide synchronization.  Fix this by moving __dev_put() from linkwatch_do_dev() to its callers. The device reference logically pairs with de-listing the device, so it's reasonable for the caller that did the de-listing to release it. This allows placing __dev_put() after all device accesses are complete, preventing UAF.  The bug can be reproduced by adding mdelay(2000) after linkwatch_do_dev() in __linkwatch_run_queue(), then running:    ip tuntap add mode tun name tun_test   ip link set tun_test up   ip link set tun_test carrier off   ip link set tun_test carrier on   sleep 0.5   ip tuntap del mode tun name tun_test  KASAN report:   ==================================================================  BUG: KASAN: use-after-free in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]  BUG: KASAN: use-after-free in netdev_unlock_ops include/net/netdev_lock.h:47 [inline]  BUG: KASAN: use-after-free in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245  Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123   CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full)  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014  Workqueue: events_unbound linkwatch_event  Call Trace:   <TASK>   __dump_stack lib/dump_stack.c:94 [inline]   dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120   print_address_description mm/kasan/report.c:378 [inline]   print_report+0x156/0x4c9 mm/kasan/report.c:482   kasan_report+0xdf/0x1a0 mm/kasan/report.c:595   netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]   netdev_unlock_ops include/net/netdev_lock.h:47 [inline]   __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245   linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304   process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257   process_scheduled_works kernel/workqueue.c:3340 [inline]   worker_thread+0x5da/0xe40 kernel/workqueue.c:3421   kthread+0x3b3/0x730 kernel/kthread.c:463   ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246   </TASK>  ==================================================================
CVE-2026-23193: In the Linux kernel, the following vulnerability has been resolved:  scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()  In iscsit_dec_session_usage_count(), the function calls complete() while holding the sess->session_usage_lock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsit_session structure immediately.  This creates a race condition where the current thread may attempt to execute spin_unlock_bh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.  To resolve this, release the session_usage_lock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.
CVE-2026-23194: In the Linux kernel, the following vulnerability has been resolved:  rust_binder: correctly handle FDA objects of length zero  Fix a bug where an empty FDA (fd array) object with 0 fds would cause an out-of-bounds error. The previous implementation used `skip == 0` to mean "this is a pointer fixup", but 0 is also the correct skip length for an empty FDA. If the FDA is at the end of the buffer, then this results in an attempt to write 8-bytes out of bounds. This is caught and results in an EINVAL error being returned to userspace.  The pattern of using `skip == 0` as a special value originates from the C-implementation of Binder. As part of fixing this bug, this pattern is replaced with a Rust enum.  I considered the alternate option of not pushing a fixup when the length is zero, but I think it's cleaner to just get rid of the zero-is-special stuff.  The root cause of this bug was diagnosed by Gemini CLI on first try. I used the following prompt:  > There appears to be a bug in @drivers/android/binder/thread.rs where > the Fixups oob bug is triggered with 316 304 316 324. This implies > that we somehow ended up with a fixup where buffer A has a pointer to > buffer B, but the pointer is located at an index in buffer A that is > out of bounds. Please investigate the code to find the bug. You may > compare with @drivers/android/binder.c that implements this correctly.
CVE-2026-23195: In the Linux kernel, the following vulnerability has been resolved:  cgroup/dmem: avoid pool UAF  An UAF issue was observed:  BUG: KASAN: slab-use-after-free in page_counter_uncharge+0x65/0x150 Write of size 8 at addr ffff888106715440 by task insmod/527  CPU: 4 UID: 0 PID: 527 Comm: insmod    6.19.0-rc7-next-20260129+ #11 Tainted: [O]=OOT_MODULE Call Trace: <TASK> dump_stack_lvl+0x82/0xd0 kasan_report+0xca/0x100 kasan_check_range+0x39/0x1c0 page_counter_uncharge+0x65/0x150 dmem_cgroup_uncharge+0x1f/0x260  Allocated by task 527:  Freed by task 0:  The buggy address belongs to the object at ffff888106715400 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 64 bytes inside of freed 512-byte region [ffff888106715400, ffff888106715600)  The buggy address belongs to the physical page:  Memory state around the buggy address: ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb          ^ ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  The issue occurs because a pool can still be held by a caller after its associated memory region is unregistered. The current implementation frees the pool even if users still hold references to it (e.g., before uncharge operations complete).  This patch adds a reference counter to each pool, ensuring that a pool is only freed when its reference count drops to zero.
CVE-2026-23196: In the Linux kernel, the following vulnerability has been resolved:  HID: Intel-thc-hid: Intel-thc: Add safety check for reading DMA buffer  Add DMA buffer readiness check before reading DMA buffer to avoid unexpected NULL pointer accessing.
CVE-2026-23197: In the Linux kernel, the following vulnerability has been resolved:  i2c: imx: preserve error state in block data length handler  When a block read returns an invalid length, zero or >I2C_SMBUS_BLOCK_MAX, the length handler sets the state to IMX_I2C_STATE_FAILED. However, i2c_imx_master_isr() unconditionally overwrites this with IMX_I2C_STATE_READ_CONTINUE, causing an endless read loop that overruns buffers and crashes the system.  Guard the state transition to preserve error states set by the length handler.
CVE-2026-23199: In the Linux kernel, the following vulnerability has been resolved:  procfs: avoid fetching build ID while holding VMA lock  Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot:   -> #1 (&mm->mmap_lock){++++}-{4:4}:         __might_fault+0xed/0x170         _copy_to_iter+0x118/0x1720         copy_page_to_iter+0x12d/0x1e0         filemap_read+0x720/0x10a0         blkdev_read_iter+0x2b5/0x4e0         vfs_read+0x7f4/0xae0         ksys_read+0x12a/0x250         do_syscall_64+0xcb/0xf80         entry_SYSCALL_64_after_hwframe+0x77/0x7f   -> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}:         __lock_acquire+0x1509/0x26d0         lock_acquire+0x185/0x340         down_read+0x98/0x490         blkdev_read_iter+0x2a7/0x4e0         __kernel_read+0x39a/0xa90         freader_fetch+0x1d5/0xa80         __build_id_parse.isra.0+0xea/0x6a0         do_procmap_query+0xd75/0x1050         procfs_procmap_ioctl+0x7a/0xb0         __x64_sys_ioctl+0x18e/0x210         do_syscall_64+0xcb/0xf80         entry_SYSCALL_64_after_hwframe+0x77/0x7f   other info that might help us debug this:    Possible unsafe locking scenario:          CPU0                    CPU1         ----                    ----    rlock(&mm->mmap_lock);                                 lock(&sb->s_type->i_mutex_key#8);                                 lock(&mm->mmap_lock);    rlock(&sb->s_type->i_mutex_key#8);    *** DEADLOCK ***  This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent:   777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")  To make this safe, we need to grab file refcount while VMA is still locked, but other than that everything is pretty straightforward. Internal build_id_parse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant build_id_parse_file() that expects file passed directly.  [akpm@linux-foundation.org: fix up kerneldoc]
CVE-2026-23201: In the Linux kernel, the following vulnerability has been resolved:  ceph: fix oops due to invalid pointer for kfree() in parse_longname()  This fixes a kernel oops when reading ceph snapshot directories (.snap), for example by simply running `ls /mnt/my_ceph/.snap`.  The variable str is guarded by __free(kfree), but advanced by one for skipping the initial '_' in snapshot names. Thus, kfree() is called with an invalid pointer.  This patch removes the need for advancing the pointer so kfree() is called with correct memory pointer.  Steps to reproduce:  1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)  2. Add cephfs mount to fstab $ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6      /mnt/test/stuff   ceph     acl,noatime,_netdev    0       0" >> /etc/fstab  3. Reboot the system $ systemctl reboot  4. Check if it's really mounted $ mount | grep stuff  5. List snapshots (expected 63 snapshots on my system) $ ls /mnt/test/stuff/.snap  Now ls hangs forever and the kernel log shows the oops.
CVE-2026-23202: In the Linux kernel, the following vulnerability has been resolved:  spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer  The curr_xfer field is read by the IRQ handler without holding the lock to check if a transfer is in progress. When clearing curr_xfer in the combined sequence transfer loop, protect it with the spinlock to prevent a race with the interrupt handler.  Protect the curr_xfer clearing at the exit path of tegra_qspi_combined_seq_xfer() with the spinlock to prevent a race with the interrupt handler that reads this field.  Without this protection, the IRQ handler could read a partially updated curr_xfer value, leading to NULL pointer dereference or use-after-free.
CVE-2026-23204: In the Linux kernel, the following vulnerability has been resolved:  net/sched: cls_u32: use skb_header_pointer_careful()  skb_header_pointer() does not fully validate negative @offset values.  Use skb_header_pointer_careful() instead.  GangMin Kim provided a report and a repro fooling u32_classify():  BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221
CVE-2026-23205: In the Linux kernel, the following vulnerability has been resolved:  smb/client: fix memory leak in smb2_open_file()  Reproducer:    1. server: directories are exported read-only   2. client: mount -t cifs //${server_ip}/export /mnt   3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct   4. client: umount /mnt   5. client: sleep 1   6. client: modprobe -r cifs  The error message is as follows:    =============================================================================   BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown()   -----------------------------------------------------------------------------    Object 0x00000000d47521be @offset=14336   ...   WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577   ...   Call Trace:    <TASK>    kmem_cache_destroy+0x94/0x190    cifs_destroy_request_bufs+0x3e/0x50 [cifs]    cleanup_module+0x4e/0x540 [cifs]    __se_sys_delete_module+0x278/0x400    __x64_sys_delete_module+0x5f/0x70    x64_sys_call+0x2299/0x2ff0    do_syscall_64+0x89/0x350    entry_SYSCALL_64_after_hwframe+0x76/0x7e   ...   kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs]   WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577
CVE-2026-23206: In the Linux kernel, the following vulnerability has been resolved:  dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zero  The driver allocates arrays for ports, FDBs, and filter blocks using kcalloc() with ethsw->sw_attr.num_ifs as the element count. When the device reports zero interfaces (either due to hardware configuration or firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10) instead of NULL.  Later in dpaa2_switch_probe(), the NAPI initialization unconditionally accesses ethsw->ports[0]->netdev, which attempts to dereference ZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.  Add a check to ensure num_ifs is greater than zero after retrieving device attributes. This prevents the zero-sized allocations and subsequent invalid pointer dereference.