xamxte/cve-to-cwe huggingface dataset:
CVE-2026-23207: In the Linux kernel, the following vulnerability has been resolved:  spi: tegra210-quad: Protect curr_xfer check in IRQ handler  Now that all other accesses to curr_xfer are done under the lock, protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the spinlock. Without this protection, the following race can occur:    CPU0 (ISR thread)              CPU1 (timeout path)   ----------------               -------------------   if (!tqspi->curr_xfer)     // sees non-NULL                                  spin_lock()                                  tqspi->curr_xfer = NULL                                  spin_unlock()   handle_*_xfer()     spin_lock()     t = tqspi->curr_xfer  // NULL!     ... t->len ...        // NULL dereference!  With this patch, all curr_xfer accesses are now properly synchronized.  Although all accesses to curr_xfer are done under the lock, in tegra_qspi_isr_thread() it checks for NULL, releases the lock and reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.  To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared curr_xfer, the handler will safely return without dereferencing the NULL pointer.
CVE-2026-23208: In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Prevent excessive number of frames  In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].  Added a check for the number of single data URB frames when calculating the number of frames to prevent [1].  [1] BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace:  copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487  prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611  prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333
CVE-2026-23209: In the Linux kernel, the following vulnerability has been resolved:  macvlan: fix error recovery in macvlan_common_newlink()  valis provided a nice repro to crash the kernel:  ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2  ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20  ping -c1 -I p1 1.2.3.4  He also gave a very detailed analysis:  <quote valis>  The issue is triggered when a new macvlan link is created  with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name).  In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink():  This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry.  vlan is a pointer to the priv data of the link that is being created.  When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create():          if (ops->newlink)                 err = ops->newlink(dev, &params, extack);         else                 err = register_netdevice(dev);         if (err < 0) {                 free_netdev(dev);                 goto out;         }  and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port.  Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().  </quote valis>  With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever "goto destroy_macvlan_port;" path is taken.  Many thanks to valis for following up on this issue.
CVE-2026-23210: In the Linux kernel, the following vulnerability has been resolved:  ice: Fix PTP NULL pointer dereference during VSI rebuild  Fix race condition where PTP periodic work runs while VSI is being rebuilt, accessing NULL vsi->rx_rings.  The sequence was: 1. ice_ptp_prepare_for_reset() cancels PTP work 2. ice_ptp_rebuild() immediately queues PTP work 3. VSI rebuild happens AFTER ice_ptp_rebuild() 4. PTP work runs and accesses NULL vsi->rx_rings  Fix: Keep PTP work cancelled during rebuild, only queue it after VSI rebuild completes in ice_rebuild().  Added ice_ptp_queue_work() helper function to encapsulate the logic for queuing PTP work, ensuring it's only queued when PTP is supported and the state is ICE_PTP_READY.  Error log: [  121.392544] ice 0000:60:00.1: PTP reset successful [  121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000 [  121.392712] #PF: supervisor read access in kernel mode [  121.392720] #PF: error_code(0x0000) - not-present page [  121.392727] PGD 0 [  121.392734] Oops: Oops: 0000 [#1] SMP NOPTI [  121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S                  6.19.0-rc6+ #4 PREEMPT(voluntary) [  121.392761] Tainted: [S]=CPU_OUT_OF_SPEC [  121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice] [  121.393042] Call Trace: [  121.393047]  <TASK> [  121.393055]  ice_ptp_periodic_work+0x69/0x180 [ice] [  121.393202]  kthread_worker_fn+0xa2/0x260 [  121.393216]  ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice] [  121.393359]  ? __pfx_kthread_worker_fn+0x10/0x10 [  121.393371]  kthread+0x10d/0x230 [  121.393382]  ? __pfx_kthread+0x10/0x10 [  121.393393]  ret_from_fork+0x273/0x2b0 [  121.393407]  ? __pfx_kthread+0x10/0x10 [  121.393417]  ret_from_fork_asm+0x1a/0x30 [  121.393432]  </TASK>
CVE-2025-59793: Rocket TRUfusion Enterprise through 7.10.5 exposes the endpoint at /axis2/services/WsPortalV6UpDwAxis2Impl to authenticated users to be able to upload files. However, the application doesn't properly sanitize the jobDirectory parameter, which allows path traversal sequences to be included. This allows writing files to arbitrary local filesystem locations and may subsequently lead to remote code execution.
CVE-2025-32355: Rocket TRUfusion Enterprise through 7.10.4.0 uses a reverse proxy to handle incoming connections. However, the proxy is misconfigured in a way that allows specifying absolute URLs in the HTTP request line, causing the proxy to load the given resource.
CVE-2025-67102: A SQL injection vulnerability in the alldayoffs feature in Jorani up to v1.0.4, allows an authenticated attacker to execute arbitrary SQL commands via the entity parameter.
CVE-2025-70846: lty628 aidigu v1.9.1 is vulnerable to Cross Site Scripting (XSS) on the /tools/Password/add page in the input field password.
CVE-2026-23212: In the Linux kernel, the following vulnerability has been resolved:  bonding: annotate data-races around slave->last_rx  slave->last_rx and slave->target_last_arp_rx[...] can be read and written locklessly. Add READ_ONCE() and WRITE_ONCE() annotations.  syzbot reported:  BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate  write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1:   bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335   bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533   __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039   __netif_receive_skb_one_core net/core/dev.c:6150 [inline]   __netif_receive_skb+0x59/0x270 net/core/dev.c:6265   netif_receive_skb_internal net/core/dev.c:6351 [inline]   netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 ...  write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0:   bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335   bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533   __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039   __netif_receive_skb_one_core net/core/dev.c:6150 [inline]   __netif_receive_skb+0x59/0x270 net/core/dev.c:6265   netif_receive_skb_internal net/core/dev.c:6351 [inline]   netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410   br_netif_receive_skb net/bridge/br_input.c:30 [inline]   NF_HOOK include/linux/netfilter.h:318 [inline] ...  value changed: 0x0000000100005365 -> 0x0000000100005366
CVE-2026-23216: In the Linux kernel, the following vulnerability has been resolved:  scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()  In iscsit_dec_conn_usage_count(), the function calls complete() while holding the conn->conn_usage_lock. As soon as complete() is invoked, the waiter (such as iscsit_close_connection()) may wake up and proceed to free the iscsit_conn structure.  If the waiter frees the memory before the current thread reaches spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function attempts to release a lock within the already-freed connection structure.  Fix this by releasing the spinlock before calling complete().
CVE-2026-23217: In the Linux kernel, the following vulnerability has been resolved:  riscv: trace: fix snapshot deadlock with sbi ecall  If sbi_ecall.c's functions are traceable,  echo "__sbi_ecall:snapshot" > /sys/kernel/tracing/set_ftrace_filter  may get the kernel into a deadlock.  (Functions in sbi_ecall.c are excluded from tracing if CONFIG_RISCV_ALTERNATIVE_EARLY is set.)  __sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code raises an IPI interrupt, which results in another call to __sbi_ecall and another snapshot...  All it takes to get into this endless loop is one initial __sbi_ecall. On RISC-V systems without SSTC extension, the clock events in timer-riscv.c issue periodic sbi ecalls, making the problem easy to trigger.  Always exclude the sbi_ecall.c functions from tracing to fix the potential deadlock.  sbi ecalls can easiliy be logged via trace events, excluding ecall functions from function tracing is not a big limitation.
CVE-2026-23218: In the Linux kernel, the following vulnerability has been resolved:  gpio: loongson-64bit: Fix incorrect NULL check after devm_kcalloc()  Fix incorrect NULL check in loongson_gpio_init_irqchip(). The function checks chip->parent instead of chip->irq.parents.
CVE-2025-71230: In the Linux kernel, the following vulnerability has been resolved:  hfs: ensure sb->s_fs_info is always cleaned up  When hfs was converted to the new mount api a bug was introduced by changing the allocation pattern of sb->s_fs_info. If setup_bdev_super() fails after a new superblock has been allocated by sget_fc(), but before hfs_fill_super() takes ownership of the filesystem-specific s_fs_info data it was leaked.  Fix this by freeing sb->s_fs_info in hfs_kill_super().
CVE-2025-71231: In the Linux kernel, the following vulnerability has been resolved:  crypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_mode  The local variable 'i' is initialized with -EINVAL, but the for loop immediately overwrites it and -EINVAL is never returned.  If no empty compression mode can be found, the function would return the out-of-bounds index IAA_COMP_MODES_MAX, which would cause an invalid array access in add_iaa_compression_mode().  Fix both issues by returning either a valid index or -EINVAL.
CVE-2025-71233: In the Linux kernel, the following vulnerability has been resolved:  PCI: endpoint: Avoid creating sub-groups asynchronously  The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes.  The crash can be easily reproduced with the following commands:    # cd /sys/kernel/config/pci_ep/functions/pci_epf_test   # for i in {1..20}; do mkdir test && rmdir test; done    BUG: kernel NULL pointer dereference, address: 0000000000000088   ...   Call Trace:    configfs_register_group+0x3d/0x190    pci_epf_cfs_work+0x41/0x110    process_one_work+0x18f/0x350    worker_thread+0x25a/0x3a0  Fix this issue by using configfs_add_default_group() API which does not have the deadlock problem as configfs_register_group() and does not require the delayed work handler.  [mani: slightly reworded the description and added stable list]
CVE-2025-71234: In the Linux kernel, the following vulnerability has been resolved:  wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_add  The driver does not set hw->sta_data_size, which causes mac80211 to allocate insufficient space for driver private station data in __sta_info_alloc(). When rtl8xxxu_sta_add() accesses members of struct rtl8xxxu_sta_info through sta->drv_priv, this results in a slab-out-of-bounds write.  KASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter:    BUG: KASAN: slab-out-of-bounds in rtl8xxxu_sta_add+0x31c/0x346   Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12  Set hw->sta_data_size to sizeof(struct rtl8xxxu_sta_info) during probe, similar to how hw->vif_data_size is configured. This ensures mac80211 allocates sufficient space for the driver's per-station private data.  Tested on StarFive VisionFive 2 v1.2A board.
CVE-2025-71236: In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Validate sp before freeing associated memory  System crash with the following signature [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3. [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5. [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000. [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000. [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [154565.553080] #PF: supervisor read access in kernel mode [154565.553082] #PF: error_code(0x0000) - not-present page [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0 [154565.553089] Oops: 0000 1 PREEMPT SMP PTI [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G           OE     -------  ---  5.14.0-503.11.1.el9_5.x86_64 #1 [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024 [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286 [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002 [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47 [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0 [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000 [154565.553152] FS:  0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000 [154565.553154] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0 [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [154565.553159] PKRU: 55555554 [154565.553160] Call Trace: [154565.553162]  <TASK> [154565.553165]  ? show_trace_log_lvl+0x1c4/0x2df [154565.553172]  ? show_trace_log_lvl+0x1c4/0x2df [154565.553177]  ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553215]  ? __die_body.cold+0x8/0xd [154565.553218]  ? page_fault_oops+0x134/0x170 [154565.553223]  ? snprintf+0x49/0x70 [154565.553229]  ? exc_page_fault+0x62/0x150 [154565.553238]  ? asm_exc_page_fault+0x22/0x30  Check for sp being non NULL before freeing any associated memory
CVE-2025-71237: In the Linux kernel, the following vulnerability has been resolved:  nilfs2: Fix potential block overflow that cause system hang  When a user executes the FITRIM command, an underflow can occur when calculating nblocks if end_block is too small. Since nblocks is of type sector_t, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdev_issue_discard() taking an excessively long time to process the bio chain, and the ns_segctor_sem lock remains held for a long period. This prevents other tasks from acquiring the ns_segctor_sem lock, resulting in the hang reported by syzbot in [1].  If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang.  Exiting successfully and assign the discarded size (0 in this case) to range->len.  Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error.  [1] task:segctord state:D stack:28968 pid:6093 tgid:6093  ppid:2 task_flags:0x200040 flags:0x00080000 Call Trace:  rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272  nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]  nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684  [ryusuke: corrected part of the commit message about the consequences]
CVE-2026-23220: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths  The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with "bad smb2 signature" messages and high CPU usage.  This patch fixes the issue by changing the return value from SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.
CVE-2026-23221: In the Linux kernel, the following vulnerability has been resolved:  bus: fsl-mc: fix use-after-free in driver_override_show()  The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock.  This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function.  Fix this by holding the device_lock around the read operation.
CVE-2026-23222: In the Linux kernel, the following vulnerability has been resolved:  crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly  The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation.  Use sizeof(*new_sg) to get the correct object size.
CVE-2026-23223: In the Linux kernel, the following vulnerability has been resolved:  xfs: fix UAF in xchk_btree_check_block_owner  We cannot dereference bs->cur when trying to determine if bs->cur aliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed. Fix this by sampling before type before any freeing could happen. The correct temporal ordering was broken when we removed xfs_btnum_t.
CVE-2026-23224: In the Linux kernel, the following vulnerability has been resolved:  erofs: fix UAF issue for file-backed mounts w/ directio option  [    9.269940][ T3222] Call trace: [    9.269948][ T3222]  ext4_file_read_iter+0xac/0x108 [    9.269979][ T3222]  vfs_iocb_iter_read+0xac/0x198 [    9.269993][ T3222]  erofs_fileio_rq_submit+0x12c/0x180 [    9.270008][ T3222]  erofs_fileio_submit_bio+0x14/0x24 [    9.270030][ T3222]  z_erofs_runqueue+0x834/0x8ac [    9.270054][ T3222]  z_erofs_read_folio+0x120/0x220 [    9.270083][ T3222]  filemap_read_folio+0x60/0x120 [    9.270102][ T3222]  filemap_fault+0xcac/0x1060 [    9.270119][ T3222]  do_pte_missing+0x2d8/0x1554 [    9.270131][ T3222]  handle_mm_fault+0x5ec/0x70c [    9.270142][ T3222]  do_page_fault+0x178/0x88c [    9.270167][ T3222]  do_translation_fault+0x38/0x54 [    9.270183][ T3222]  do_mem_abort+0x54/0xac [    9.270208][ T3222]  el0_da+0x44/0x7c [    9.270227][ T3222]  el0t_64_sync_handler+0x5c/0xf4 [    9.270253][ T3222]  el0t_64_sync+0x1bc/0x1c0  EROFS may encounter above panic when enabling file-backed mount w/ directio mount option, the root cause is it may suffer UAF in below race condition:  - z_erofs_read_folio                          wq s_dio_done_wq  - z_erofs_runqueue   - erofs_fileio_submit_bio    - erofs_fileio_rq_submit     - vfs_iocb_iter_read      - ext4_file_read_iter       - ext4_dio_read_iter        - iomap_dio_rw        : bio was submitted and return -EIOCBQUEUED                                               - dio_aio_complete_work                                                - dio_complete                                                 - dio->iocb->ki_complete (erofs_fileio_ki_complete())                                                  - kfree(rq)                                                  : it frees iocb, iocb.ki_filp can be UAF in file_accessed().        - file_accessed        : access NULL file point  Introduce a reference count in struct erofs_fileio_rq, and initialize it as two, both erofs_fileio_ki_complete() and erofs_fileio_rq_submit() will decrease reference count, the last one decreasing the reference count to zero will free rq.
CVE-2026-23227: In the Linux kernel, the following vulnerability has been resolved:  drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free  Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem.  For example, use-after-free can occur in race scenario like this: ```  CPU0    CPU1    CPU2  ----    ----    ----   vidi_connection_ioctl()     if (vidi->connection) // true       drm_edid = drm_edid_alloc(); // alloc drm_edid       ...       ctx->raw_edid = drm_edid;       ...         drm_mode_getconnector()           drm_helper_probe_single_connector_modes()             vidi_get_modes()               if (ctx->raw_edid) // true                 drm_edid_dup(ctx->raw_edid);                   if (!drm_edid) // false                   ...     vidi_connection_ioctl()       if (vidi->connection) // false         drm_edid_free(ctx->raw_edid); // free drm_edid         ...                   drm_edid_alloc(drm_edid->edid)                     kmemdup(edid); // UAF!!                     ... ```  To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock.
CVE-2026-23228: In the Linux kernel, the following vulnerability has been resolved:  smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()  On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is freed via free_transport(), which does not decrement active_num_conn, leaking this counter.  Replace free_transport() with ksmbd_tcp_disconnect().