xamxte/cve-to-cwe huggingface dataset:
CVE-2026-23159: In the Linux kernel, the following vulnerability has been resolved:  perf: sched: Fix perf crash with new is_user_task() helper  In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the task_struct mm field. If it was non NULL, it was a user task and if not it was a kernel task.  But things have changed over time, and some kernel tasks now have their own mm field.  An idea was made to instead test PF_KTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PF_KTHREAD directly.  It was later found that not all kernel threads set PF_KTHREAD. The io-uring helpers instead set PF_USER_WORKER and this needed to be added as well.  But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference.  Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field.  Instead of making this modification in every location, create a new is_user_task() helper function that does all the tests needed to know if it is safe to read the user space memory or not.  [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/
CVE-2026-23160: In the Linux kernel, the following vulnerability has been resolved:  octeon_ep: Fix memory leak in octep_device_setup()  In octep_device_setup(), if octep_ctrl_net_init() fails, the function returns directly without unmapping the mapped resources and freeing the allocated configuration memory.  Fix this by jumping to the unsupported_dev label, which performs the necessary cleanup. This aligns with the error handling logic of other paths in this function.  Compile tested only. Issue found using a prototype static analysis tool and code review.
CVE-2026-23161: In the Linux kernel, the following vulnerability has been resolved:  mm/shmem, swap: fix race of truncate and swap entry split  The helper for shmem swap freeing is not handling the order of swap entries correctly.  It uses xa_cmpxchg_irq to erase the swap entry, but it gets the entry order before that using xa_get_order without lock protection, and it may get an outdated order value if the entry is split or changed in other ways after the xa_get_order and before the xa_cmpxchg_irq.  And besides, the order could grow and be larger than expected, and cause truncation to erase data beyond the end border.  For example, if the target entry and following entries are swapped in or freed, then a large folio was added in place and swapped out, using the same entry, the xa_cmpxchg_irq will still succeed, it's very unlikely to happen though.  To fix that, open code the Xarray cmpxchg and put the order retrieval and value checking in the same critical section.  Also, ensure the order won't exceed the end border, skip it if the entry goes across the border.  Skipping large swap entries crosses the end border is safe here.  Shmem truncate iterates the range twice, in the first iteration, find_lock_entries already filtered such entries, and shmem will swapin the entries that cross the end border and partially truncate the folio (split the folio or at least zero part of it).  So in the second loop here, if we see a swap entry that crosses the end order, it must at least have its content erased already.  I observed random swapoff hangs and kernel panics when stress testing ZSWAP with shmem.  After applying this patch, all problems are gone.
CVE-2026-23162: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/nvm: Fix double-free on aux add failure  After a successful auxiliary_device_init(), aux_dev->dev.release (xe_nvm_release_dev()) is responsible for the kfree(nvm). When there is failure with auxiliary_device_add(), driver will call auxiliary_device_uninit(), which call put_device(). So that the .release callback will be triggered to free the memory associated with the auxiliary_device.  Move the kfree(nvm) into the auxiliary_device_init() failure path and remove the err goto path to fix below error.  " [   13.232905] ================================================================== [   13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe] [   13.233112] Free of addr ffff888120635000 by task systemd-udevd/273  [   13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary) ... [   13.233125] Call Trace: [   13.233126]  <TASK> [   13.233127]  dump_stack_lvl+0x7f/0xc0 [   13.233132]  print_report+0xce/0x610 [   13.233136]  ? kasan_complete_mode_report_info+0x5d/0x1e0 [   13.233139]  ? xe_nvm_init+0x751/0xf10 [xe] ... "  v2: drop err goto path. (Alexander)  (cherry picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215)
CVE-2026-23163: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove  On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and ih2 interrupt ring buffers are not initialized. This is by design, as these secondary IH rings are only available on discrete GPUs. See vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when AMD_IS_APU is set.  However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to get the timestamp of the last interrupt entry. When retry faults are enabled on APUs (noretry=0), this function is called from the SVM page fault recovery path, resulting in a NULL pointer dereference when amdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[].  The crash manifests as:    BUG: kernel NULL pointer dereference, address: 0000000000000004   RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]   Call Trace:    amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]    svm_range_restore_pages+0xae5/0x11c0 [amdgpu]    amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]    gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]    amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]    amdgpu_ih_process+0x84/0x100 [amdgpu]  This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1") which changed the default for Renoir APU from noretry=1 to noretry=0, enabling retry fault handling and thus exercising the buggy code path.  Fix this by adding a check for ih1.ring_size before attempting to use it. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu: Rework retry fault removal").  This is needed if the hardware doesn't support secondary HW IH rings.  v2: additional updates (Alex)  (cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)
CVE-2026-23164: In the Linux kernel, the following vulnerability has been resolved:  rocker: fix memory leak in rocker_world_port_post_fini()  In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set:      if (!wops->port_post_fini)         return;     wops->port_post_fini(rocker_port);     kfree(rocker_port->wpriv);  Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal.  Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.
CVE-2026-23165: In the Linux kernel, the following vulnerability has been resolved:  sfc: fix deadlock in RSS config read  Since cited commit, core locks the net_device's rss_lock when handling  ethtool -x command, so driver's implementation should not lock it  again.  Remove the latter.
CVE-2026-23166: In the Linux kernel, the following vulnerability has been resolved:  ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues  Add NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashes during resume from suspend when rings[q_idx]->q_vector is NULL.  Tested adaptor: 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02)         Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]  SR-IOV state: both disabled and enabled can reproduce this issue.  kernel version: v6.18  Reproduce steps: Boot up and execute suspend like systemctl suspend or rtcwake.  Log: <1>[  231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040 <1>[  231.444052] #PF: supervisor read access in kernel mode <1>[  231.444484] #PF: error_code(0x0000) - not-present page <6>[  231.444913] PGD 0 P4D 0 <4>[  231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[  231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170 <4>[  231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[  231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[  231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010 <4>[  231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000 <4>[  231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[  231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[  231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000 <4>[  231.450265] FS:  00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[  231.450715] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[  231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[  231.451629] PKRU: 55555554 <4>[  231.452076] Call Trace: <4>[  231.452549]  <TASK> <4>[  231.452996]  ? ice_vsi_set_napi_queues+0x4d/0x110 [ice] <4>[  231.453482]  ice_resume+0xfd/0x220 [ice] <4>[  231.453977]  ? __pfx_pci_pm_resume+0x10/0x10 <4>[  231.454425]  pci_pm_resume+0x8c/0x140 <4>[  231.454872]  ? __pfx_pci_pm_resume+0x10/0x10 <4>[  231.455347]  dpm_run_callback+0x5f/0x160 <4>[  231.455796]  ? dpm_wait_for_superior+0x107/0x170 <4>[  231.456244]  device_resume+0x177/0x270 <4>[  231.456708]  dpm_resume+0x209/0x2f0 <4>[  231.457151]  dpm_resume_end+0x15/0x30 <4>[  231.457596]  suspend_devices_and_enter+0x1da/0x2b0 <4>[  231.458054]  enter_state+0x10e/0x570  Add defensive checks for both the ring pointer and its q_vector before dereferencing, allowing the system to resume successfully even when q_vectors are unmapped.
CVE-2026-23168: In the Linux kernel, the following vulnerability has been resolved:  flex_proportions: make fprop_new_period() hardirq safe  Bernd has reported a lockdep splat from flexible proportions code that is essentially complaining about the following race:  <timer fires> run_timer_softirq - we are in softirq context   call_timer_fn     writeout_period       fprop_new_period         write_seqcount_begin(&p->sequence);          <hardirq is raised>         ...         blk_mq_end_request()    blk_update_request()      ext4_end_bio()        folio_end_writeback()   __wb_writeout_add()     __fprop_add_percpu_max()       if (unlikely(max_frac < FPROP_FRAC_BASE)) {         fprop_fraction_percpu()    seq = read_seqcount_begin(&p->sequence);      - sees odd sequence so loops indefinitely  Note that a deadlock like this is only possible if the bdi has configured maximum fraction of writeout throughput which is very rare in general but frequent for example for FUSE bdis.  To fix this problem we have to make sure write section of the sequence counter is irqsafe.
CVE-2026-23169: In the Linux kernel, the following vulnerability has been resolved:  mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()  syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup()  Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready.  list_splice_init_rcu() can not be called here while holding pernet->lock spinlock.  Many thanks to Eulgyu Kim for providing a repro and testing our patches.
CVE-2026-23170: In the Linux kernel, the following vulnerability has been resolved:  drm/imx/tve: fix probe device leak  Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.
CVE-2026-23171: In the Linux kernel, the following vulnerability has been resolved:  bonding: fix use-after-free due to enslave fail after slave array update  Fix a use-after-free which happens due to enslave failure after the new slave has been added to the array. Since the new slave can be used for Tx immediately, we can use it after it has been freed by the enslave error cleanup path which frees the allocated slave memory. Slave update array is supposed to be called last when further enslave failures are not expected. Move it after xdp setup to avoid any problems.  It is very easy to reproduce the problem with a simple xdp_pass prog:  ip l add bond1 type bond mode balance-xor  ip l set bond1 up  ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass  ip l add dumdum type dummy  Then run in parallel:  while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done;  mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"  The crash happens almost immediately:  [  605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI  [  605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]  [  605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G    B               6.19.0-rc6+ #21 PREEMPT(voluntary)  [  605.602979] Tainted: [B]=BAD_PAGE  [  605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014  [  605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210  [  605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89  [  605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213  [  605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000  [  605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be  [  605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c  [  605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000  [  605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84  [  605.603286] FS:  00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000  [  605.603319] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  [  605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0  [  605.603373] Call Trace:  [  605.603392]  <TASK>  [  605.603410]  __dev_queue_xmit+0x448/0x32a0  [  605.603434]  ? __pfx_vprintk_emit+0x10/0x10  [  605.603461]  ? __pfx_vprintk_emit+0x10/0x10  [  605.603484]  ? __pfx___dev_queue_xmit+0x10/0x10  [  605.603507]  ? bond_start_xmit+0xbfb/0xc20 [bonding]  [  605.603546]  ? _printk+0xcb/0x100  [  605.603566]  ? __pfx__printk+0x10/0x10  [  605.603589]  ? bond_start_xmit+0xbfb/0xc20 [bonding]  [  605.603627]  ? add_taint+0x5e/0x70  [  605.603648]  ? add_taint+0x2a/0x70  [  605.603670]  ? end_report.cold+0x51/0x75  [  605.603693]  ? bond_start_xmit+0xbfb/0xc20 [bonding]  [  605.603731]  bond_start_xmit+0x623/0xc20 [bonding]
CVE-2026-23172: In the Linux kernel, the following vulnerability has been resolved:  net: wwan: t7xx: fix potential skb->frags overflow in RX path  When receiving data in the DPMAIF RX path, the t7xx_dpmaif_set_frag_to_skb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow in skb_shinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior.  This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76: fix array overflow on receiving too many fragments for a packet").  The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects.  Fix this by adding a bounds check before calling skb_add_rx_frag() to ensure nr_frags does not exceed MAX_SKB_FRAGS.  The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown.
CVE-2025-71203: In the Linux kernel, the following vulnerability has been resolved:  riscv: Sanitize syscall table indexing under speculation  The syscall number is a user-controlled value used to index into the syscall table. Use array_index_nospec() to clamp this value after the bounds check to prevent speculative out-of-bounds access and subsequent data leakage via cache side channels.
CVE-2025-71204: In the Linux kernel, the following vulnerability has been resolved:  smb/server: fix refcount leak in parse_durable_handle_context()  When the command is a replay operation and -ENOEXEC is returned, the refcount of ksmbd_file must be released.
CVE-2025-71221: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()  Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and descriptor contents.  The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors:  CPU 0                              CPU 1 -----                              ----- mmp_pdma_tx_status() mmp_pdma_residue()   -> NO LOCK held      list_for_each_entry(sw, ..)                                    DMA interrupt                                    dma_do_tasklet()                                      -> spin_lock(&desc_lock)                                         list_move(sw->node, ...)                                         spin_unlock(&desc_lock)   |                                     dma_pool_free(sw) <- FREED!   -> access sw->desc <- UAF!  This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1).  Fix by protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.
CVE-2025-71222: In the Linux kernel, the following vulnerability has been resolved:  wifi: wlcore: ensure skb headroom before skb_push  This avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom is less than needed (typically 110 - 94 = 16 bytes).
CVE-2025-71223: In the Linux kernel, the following vulnerability has been resolved:  smb/server: fix refcount leak in smb2_open()  When ksmbd_vfs_getattr() fails, the reference count of ksmbd_file must be released.
CVE-2026-23174: In the Linux kernel, the following vulnerability has been resolved:  nvme-pci: handle changing device dma map requirements  The initial state of dma_needs_unmap may be false, but change to true while mapping the data iterator. Enabling swiotlb is one such case that can change the result. The nvme driver needs to save the mapped dma vectors to be unmapped later, so allocate as needed during iteration rather than assume it was always allocated at the beginning. This fixes a NULL dereference from accessing an uninitialized dma_vecs when the device dma unmapping requirements change mid-iteration.
CVE-2026-23176: In the Linux kernel, the following vulnerability has been resolved:  platform/x86: toshiba_haps: Fix memory leaks in add/remove routines  toshiba_haps_add() leaks the haps object allocated by it if it returns an error after allocating that object successfully.  toshiba_haps_remove() does not free the object pointed to by toshiba_haps before clearing that pointer, so it becomes unreachable allocated memory.  Address these memory leaks by using devm_kzalloc() for allocating the memory in question.
CVE-2026-23177: In the Linux kernel, the following vulnerability has been resolved:  mm, shmem: prevent infinite loop on truncate race  When truncating a large swap entry, shmem_free_swap() returns 0 when the entry's index doesn't match the given index due to lookup alignment.  The failure fallback path checks if the entry crosses the end border and aborts when it happens, so truncate won't erase an unexpected entry or range.  But one scenario was ignored.  When `index` points to the middle of a large swap entry, and the large swap entry doesn't go across the end border, find_get_entries() will return that large swap entry as the first item in the batch with `indices[0]` equal to `index`.  The entry's base index will be smaller than `indices[0]`, so shmem_free_swap() will fail and return 0 due to the "base < index" check.  The code will then call shmem_confirm_swap(), get the order, check if it crosses the END boundary (which it doesn't), and retry with the same index.  The next iteration will find the same entry again at the same index with same indices, leading to an infinite loop.  Fix this by retrying with a round-down index, and abort if the index is smaller than the truncate range.
CVE-2026-23178: In the Linux kernel, the following vulnerability has been resolved:  HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()  `i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of data into `ihid->rawbuf`.  The former can come from the userspace in the hidraw driver and is only bounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set `max_buffer_size` field of `struct hid_ll_driver` which we do not).  The latter has size determined at runtime by the maximum size of different report types you could receive on any particular device and can be a much smaller value.  Fix this by truncating `recv_len` to `ihid->bufsize - sizeof(__le16)`.  The impact is low since access to hidraw devices requires root.
CVE-2026-23179: In the Linux kernel, the following vulnerability has been resolved:  nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready()  When the socket is closed while in TCP_LISTEN a callback is run to flush all outstanding packets, which in turns calls nvmet_tcp_listen_data_ready() with the sk_callback_lock held. So we need to check if we are in TCP_LISTEN before attempting to get the sk_callback_lock() to avoid a deadlock.
CVE-2026-23180: In the Linux kernel, the following vulnerability has been resolved:  dpaa2-switch: add bounds check for if_id in IRQ handler  The IRQ handler extracts if_id from the upper 16 bits of the hardware status register and uses it to index into ethsw->ports[] without validation. Since if_id can be any 16-bit value (0-65535) but the ports array is only allocated with sw_attr.num_ifs elements, this can lead to an out-of-bounds read potentially.  Add a bounds check before accessing the array, consistent with the existing validation in dpaa2_switch_rx().
CVE-2026-23182: In the Linux kernel, the following vulnerability has been resolved:  spi: tegra: Fix a memory leak in tegra_slink_probe()  In tegra_slink_probe(), when platform_get_irq() fails, it directly returns from the function with an error code, which causes a memory leak.  Replace it with a goto label to ensure proper cleanup.