xamxte/cve-to-cwe huggingface dataset:
CVE-2025-68792: In the Linux kernel, the following vulnerability has been resolved:  tpm2-sessions: Fix out of range indexing in name_size  'name_size' does not have any range checks, and it just directly indexes with TPM_ALG_ID, which could lead into memory corruption at worst.  Address the issue by only processing known values and returning -EINVAL for unrecognized values.  Make also 'tpm_buf_append_name' and 'tpm_buf_fill_hmac_session' fallible so that errors are detected before causing any spurious TPM traffic.  End also the authorization session on failure in both of the functions, as the session state would be then by definition corrupted.
CVE-2025-68793: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix a job->pasid access race in gpu recovery  Avoid a possible UAF in GPU recovery due to a race between the sched timeout callback and the tdr work queue.  The gpu recovery function calls drm_sched_stop() and later drm_sched_start().  drm_sched_start() restarts the tdr queue which will eventually free the job.  If the tdr queue frees the job before time out callback completes, the job will be freed and we'll get a UAF when accessing the pasid.  Cache it early to avoid the UAF.  Example KASAN trace: [  493.058141] BUG: KASAN: slab-use-after-free in amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [  493.067530] Read of size 4 at addr ffff88b0ce3f794c by task kworker/u128:1/323 [  493.074892] [  493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G            E       6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntary) [  493.076493] Tainted: [E]=UNSIGNED_MODULE [  493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019 [  493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched] [  493.076512] Call Trace: [  493.076515]  <TASK> [  493.076518]  dump_stack_lvl+0x64/0x80 [  493.076529]  print_report+0xce/0x630 [  493.076536]  ? _raw_spin_lock_irqsave+0x86/0xd0 [  493.076541]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [  493.076545]  ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [  493.077253]  kasan_report+0xb8/0xf0 [  493.077258]  ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [  493.077965]  amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [  493.078672]  ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu] [  493.079378]  ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu] [  493.080111]  amdgpu_job_timedout+0x642/0x1400 [amdgpu] [  493.080903]  ? pick_task_fair+0x24e/0x330 [  493.080910]  ? __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu] [  493.081702]  ? _raw_spin_lock+0x75/0xc0 [  493.081708]  ? __pfx__raw_spin_lock+0x10/0x10 [  493.081712]  drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched] [  493.081721]  ? __pfx__raw_spin_lock_irq+0x10/0x10 [  493.081725]  process_one_work+0x679/0xff0 [  493.081732]  worker_thread+0x6ce/0xfd0 [  493.081736]  ? __pfx_worker_thread+0x10/0x10 [  493.081739]  kthread+0x376/0x730 [  493.081744]  ? __pfx_kthread+0x10/0x10 [  493.081748]  ? __pfx__raw_spin_lock_irq+0x10/0x10 [  493.081751]  ? __pfx_kthread+0x10/0x10 [  493.081755]  ret_from_fork+0x247/0x330 [  493.081761]  ? __pfx_kthread+0x10/0x10 [  493.081764]  ret_from_fork_asm+0x1a/0x30 [  493.081771]  </TASK>  (cherry picked from commit 20880a3fd5dd7bca1a079534cf6596bda92e107d)
CVE-2025-68795: In the Linux kernel, the following vulnerability has been resolved:  ethtool: Avoid overflowing userspace buffer on stats query  The ethtool -S command operates across three ioctl calls: ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and ETHTOOL_GSTATS for the values.  If the number of stats changes between these calls (e.g., due to device reconfiguration), userspace's buffer allocation will be incorrect, potentially leading to buffer overflow.  Drivers are generally expected to maintain stable stat counts, but some drivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making this scenario possible.  Some drivers try to handle this internally: - bnad_get_ethtool_stats() returns early in case stats.n_stats is not   equal to the driver's stats count. - micrel/ksz884x also makes sure not to write anything beyond   stats.n_stats and overflow the buffer.  However, both use stats.n_stats which is already assigned with the value returned from get_sset_count(), hence won't solve the issue described here.  Change ethtool_get_strings(), ethtool_get_stats(), ethtool_get_phy_stats() to not return anything in case of a mismatch between userspace's size and get_sset_size(), to prevent buffer overflow. The returned n_stats value will be equal to zero, to reflect that nothing has been returned.  This could result in one of two cases when using upstream ethtool, depending on when the size change is detected: 1. When detected in ethtool_get_strings():     # ethtool -S eth2     no stats available  2. When detected in get stats, all stats will be reported as zero.  Both cases are presumably transient, and a subsequent ethtool call should succeed.  Other than the overflow avoidance, these two cases are very evident (no output/cleared stats), which is arguably better than presenting incorrect/shifted stats. I also considered returning an error instead of a "silent" response, but that seems more destructive towards userspace apps.  Notes: - This patch does not claim to fix the inherent race, it only makes sure   that we do not overflow the userspace buffer, and makes for a more   predictable behavior.  - RTNL lock is held during each ioctl, the race window exists between   the separate ioctl calls when the lock is released.  - Userspace ethtool always fills stats.n_stats, but it is likely that   these stats ioctls are implemented in other userspace applications   which might not fill it. The added code checks that it's not zero,   to prevent any regressions.
CVE-2025-68797: In the Linux kernel, the following vulnerability has been resolved:  char: applicom: fix NULL pointer dereference in ac_ioctl  Discovered by Atuin - Automated Vulnerability Discovery Engine.  In ac_ioctl, the validation of IndexCard and the check for a valid RamIO pointer are skipped when cmd is 6. However, the function unconditionally executes readb(apbs[IndexCard].RamIO + VERS) at the end.  If cmd is 6, IndexCard may reference a board that does not exist (where RamIO is NULL), leading to a NULL pointer dereference.  Fix this by skipping the readb access when cmd is 6, as this command is a global information query and does not target a specific board context.
CVE-2025-68798: In the Linux kernel, the following vulnerability has been resolved:  perf/x86/amd: Check event before enable to avoid GPF  On AMD machines cpuc->events[idx] can become NULL in a subtle race condition with NMI->throttle->x86_pmu_stop().  Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF. This appears to be an AMD only issue.  Syzkaller reported a GPF in amd_pmu_enable_all.  INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143     msecs Oops: general protection fault, probably for non-canonical address     0xdffffc0000000034: 0000  PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7] CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195     arch/x86/events/core.c:1430) RSP: 0018:ffff888118009d60 EFLAGS: 00010012 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601 FS:  00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0 Call Trace:  <IRQ> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2)) x86_pmu_enable (arch/x86/events/core.c:1360) event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186     kernel/events/core.c:2346) __perf_remove_from_context (kernel/events/core.c:2435) event_function (kernel/events/core.c:259) remote_function (kernel/events/core.c:92 (discriminator 1)     kernel/events/core.c:72 (discriminator 1)) __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27     ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64     kernel/smp.c:135 kernel/smp.c:540) __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27     ./include/linux/jump_label.h:207     ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272) sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)     arch/x86/kernel/smp.c:266 (discriminator 47))  </IRQ>
CVE-2025-68799: In the Linux kernel, the following vulnerability has been resolved:  caif: fix integer underflow in cffrml_receive()  The cffrml_receive() function extracts a length field from the packet header and, when FCS is disabled, subtracts 2 from this length without validating that len >= 2.  If an attacker sends a malicious packet with a length field of 0 or 1 to an interface with FCS disabled, the subtraction causes an integer underflow.  This can lead to memory exhaustion and kernel instability, potential information disclosure if padding contains uninitialized kernel memory.  Fix this by validating that len >= 2 before performing the subtraction.
CVE-2025-68800: In the Linux kernel, the following vulnerability has been resolved:  mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats  Cited commit added a dedicated mutex (instead of RTNL) to protect the multicast route list, so that it will not change while the driver periodically traverses it in order to update the kernel about multicast route stats that were queried from the device.  One instance of list entry deletion (during route replace) was missed and it can result in a use-after-free [1].  Fix by acquiring the mutex before deleting the entry from the list and releasing it afterwards.  [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043  CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum] Call Trace:  <TASK>  dump_stack_lvl+0xba/0x110  print_report+0x174/0x4f5  kasan_report+0xdf/0x110  mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]  process_one_work+0x9cc/0x18e0  worker_thread+0x5df/0xe40  kthread+0x3b8/0x730  ret_from_fork+0x3e9/0x560  ret_from_fork_asm+0x1a/0x30  </TASK>  Allocated by task 29933:  kasan_save_stack+0x30/0x50  kasan_save_track+0x14/0x30  __kasan_kmalloc+0x8f/0xa0  mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]  mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]  process_one_work+0x9cc/0x18e0  worker_thread+0x5df/0xe40  kthread+0x3b8/0x730  ret_from_fork+0x3e9/0x560  ret_from_fork_asm+0x1a/0x30  Freed by task 29933:  kasan_save_stack+0x30/0x50  kasan_save_track+0x14/0x30  __kasan_save_free_info+0x3b/0x70  __kasan_slab_free+0x43/0x70  kfree+0x14e/0x700  mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]  mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]  process_one_work+0x9cc/0x18e0  worker_thread+0x5df/0xe40  kthread+0x3b8/0x730  ret_from_fork+0x3e9/0x560  ret_from_fork_asm+0x1a/0x30
CVE-2025-68802: In the Linux kernel, the following vulnerability has been resolved:  drm/xe: Limit num_syncs to prevent oversized allocations  The exec and vm_bind ioctl allow userspace to specify an arbitrary num_syncs value. Without bounds checking, a very large num_syncs can force an excessively large allocation, leading to kernel warnings from the page allocator as below.  Introduce DRM_XE_MAX_SYNCS (set to 1024) and reject any request exceeding this limit.  " ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124 ... Call Trace:  <TASK>  alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416  ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317  __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348  __do_kmalloc_node mm/slub.c:4364 [inline]  __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388  kmalloc_noprof include/linux/slab.h:909 [inline]  kmalloc_array_noprof include/linux/slab.h:948 [inline]  xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158  drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797  drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894  xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:598 [inline]  __se_sys_ioctl fs/ioctl.c:584 [inline]  __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f ... "  v2: Add "Reported-by" and Cc stable kernels. v3: Change XE_MAX_SYNCS from 64 to 1024. (Matt & Ashutosh) v4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt) v5: Do the check at the top of the exec func. (Matt)  (cherry picked from commit b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c)
CVE-2025-68804: In the Linux kernel, the following vulnerability has been resolved:  platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver  After unbinding the driver, another kthread `cros_ec_console_log_work` is still accessing the device, resulting an UAF and crash.  The driver doesn't unregister the EC device in .remove() which should shutdown sub-devices synchronously.  Fix it.
CVE-2025-68805: In the Linux kernel, the following vulnerability has been resolved:  fuse: fix io-uring list corruption for terminated non-committed requests  When a request is terminated before it has been committed, the request is not removed from the queue's list. This leaves a dangling list entry that leads to list corruption and use-after-free issues.  Remove the request from the queue's list for terminated non-committed requests.
CVE-2025-68806: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix buffer validation by including null terminator size in EA length  The smb2_set_ea function, which handles Extended Attributes (EA), was performing buffer validation checks that incorrectly omitted the size of the null terminating character (+1 byte) for EA Name. This patch fixes the issue by explicitly adding '+ 1' to EaNameLength where the null terminator is expected to be present in the buffer, ensuring the validation accurately reflects the total required buffer size.
CVE-2025-68807: In the Linux kernel, the following vulnerability has been resolved:  block: fix race between wbt_enable_default and IO submission  When wbt_enable_default() is moved out of queue freezing in elevator_change(), it can cause the wbt inflight counter to become negative (-1), leading to hung tasks in the writeback path. Tasks get stuck in wbt_wait() because the counter is in an inconsistent state.  The issue occurs because wbt_enable_default() could race with IO submission, allowing the counter to be decremented before proper initialization. This manifests as:    rq_wait[0]:     inflight:             -1     has_waiters:        True  rwb_enabled() checks the state, which can be updated exactly between wbt_wait() (rq_qos_throttle()) and wbt_track()(rq_qos_track()), then the inflight counter will become negative.  And results in hung task warnings like:   task:kworker/u24:39 state:D stack:0 pid:14767   Call Trace:     rq_qos_wait+0xb4/0x150     wbt_wait+0xa9/0x100     __rq_qos_throttle+0x24/0x40     blk_mq_submit_bio+0x672/0x7b0     ...  Fix this by:  1. Splitting wbt_enable_default() into:    - __wbt_enable_default(): Returns true if wbt_init() should be called    - wbt_enable_default(): Wrapper for existing callers (no init)    - wbt_init_enable_default(): New function that checks and inits WBT  2. Using wbt_init_enable_default() in blk_register_queue() to ensure    proper initialization during queue registration  3. Move wbt_init() out of wbt_enable_default() which is only for enabling    disabled wbt from bfq and iocost, and wbt_init() isn't needed. Then the    original lock warning can be avoided.  4. Removing the ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT flag and its handling    code since it's no longer needed  This ensures WBT is properly initialized before any IO can be submitted, preventing the counter from going negative.
CVE-2025-68808: In the Linux kernel, the following vulnerability has been resolved:  media: vidtv: initialize local pointers upon transfer of memory ownership  vidtv_channel_si_init() creates a temporary list (program, service, event) and ownership of the memory itself is transferred to the PAT/SDT/EIT tables through vidtv_psi_pat_program_assign(), vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().  The problem here is that the local pointer where the memory ownership transfer was completed is not initialized to NULL. This causes the vidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, and in the flow that jumps to free_eit, the memory that was freed by vidtv_psi_*_table_destroy() can be accessed again by vidtv_psi_*_event_destroy() due to the uninitialized local pointer, so it is freed once again.  Therefore, to prevent use-after-free and double-free vulnerability, local pointers must be initialized to NULL when transferring memory ownership.
CVE-2025-68809: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: vfs: fix race on m_flags in vfs_cache  ksmbd maintains delete-on-close and pending-delete state in ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under inconsistent locking: some paths read and modify m_flags under ci->m_lock while others do so without taking the lock at all.  Examples:   - ksmbd_query_inode_status() and __ksmbd_inode_close() use    ci->m_lock when checking or updating m_flags.  - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),    ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close()    used to read and modify m_flags without ci->m_lock.  This creates a potential data race on m_flags when multiple threads open, close and delete the same file concurrently. In the worst case delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use).  Fix it by:   - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock    after dropping inode_hash_lock.  - Adding ci->m_lock protection to all helpers that read or modify    m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),    ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).  - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(),    and moving the actual unlink/xattr removal outside the lock.  This unifies the locking around m_flags and removes the data race while preserving the existing delete-on-close behaviour.
CVE-2025-68810: In the Linux kernel, the following vulnerability has been resolved:  KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslot  Reject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that was initially created with a guest_memfd binding, as KVM doesn't support toggling KVM_MEM_GUEST_MEMFD on existing memslots.  KVM prevents enabling KVM_MEM_GUEST_MEMFD, but doesn't prevent clearing the flag.  Failure to reject the new memslot results in a use-after-free due to KVM not unbinding from the guest_memfd instance.  Unbinding on a FLAGS_ONLY change is easy enough, and can/will be done as a hardening measure (in anticipation of KVM supporting dirty logging on guest_memfd at some point), but fixing the use-after-free would only address the immediate symptom.    ==================================================================   BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm]   Write of size 8 at addr ffff8881111ae908 by task repro/745    CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015   Call Trace:    <TASK>    dump_stack_lvl+0x51/0x60    print_report+0xcb/0x5c0    kasan_report+0xb4/0xe0    kvm_gmem_release+0x362/0x400 [kvm]    __fput+0x2fa/0x9d0    task_work_run+0x12c/0x200    do_exit+0x6ae/0x2100    do_group_exit+0xa8/0x230    __x64_sys_exit_group+0x3a/0x50    x64_sys_call+0x737/0x740    do_syscall_64+0x5b/0x900    entry_SYSCALL_64_after_hwframe+0x4b/0x53   RIP: 0033:0x7f581f2eac31    </TASK>    Allocated by task 745 on cpu 6 at 9.746971s:    kasan_save_stack+0x20/0x40    kasan_save_track+0x13/0x50    __kasan_kmalloc+0x77/0x90    kvm_set_memory_region.part.0+0x652/0x1110 [kvm]    kvm_vm_ioctl+0x14b0/0x3290 [kvm]    __x64_sys_ioctl+0x129/0x1a0    do_syscall_64+0x5b/0x900    entry_SYSCALL_64_after_hwframe+0x4b/0x53    Freed by task 745 on cpu 6 at 9.747467s:    kasan_save_stack+0x20/0x40    kasan_save_track+0x13/0x50    __kasan_save_free_info+0x37/0x50    __kasan_slab_free+0x3b/0x60    kfree+0xf5/0x440    kvm_set_memslot+0x3c2/0x1160 [kvm]    kvm_set_memory_region.part.0+0x86a/0x1110 [kvm]    kvm_vm_ioctl+0x14b0/0x3290 [kvm]    __x64_sys_ioctl+0x129/0x1a0    do_syscall_64+0x5b/0x900    entry_SYSCALL_64_after_hwframe+0x4b/0x53
CVE-2025-68811: In the Linux kernel, the following vulnerability has been resolved:  svcrdma: use rc_pageoff for memcpy byte offset  svc_rdma_copy_inline_range added rc_curpage (page index) to the page base instead of the byte offset rc_pageoff. Use rc_pageoff so copies land within the current page.  Found by ZeroPath (https://zeropath.com)
CVE-2025-68812: In the Linux kernel, the following vulnerability has been resolved:  media: iris: Add sanity check for stop streaming  Add sanity check in iris_vb2_stop_streaming. If inst->state is already IRIS_INST_ERROR, we should skip the stream_off operation because it would still send packets to the firmware.  In iris_kill_session, inst->state is set to IRIS_INST_ERROR and session_close is executed, which will kfree(inst_hfi_gen2->packet). If stop_streaming is called afterward, it will cause a crash.  [bod: remove qcom from patch title]