xamxte/cve-to-cwe huggingface dataset:
CVE-2025-40354: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: increase max link count and fix link->enc NULL pointer access  [why] 1.) dc->links[MAX_LINKS] array size smaller than actual requested. max_connector + max_dpia + 4 virtual = 14. increase from 12 to 14.  2.) hw_init() access null LINK_ENC for dpia non display_endpoint.  (cherry picked from commit d7f5a61e1b04ed87b008c8d327649d184dc5bb45)
CVE-2025-40357: In the Linux kernel, the following vulnerability has been resolved:  net/smc: fix general protection fault in __smc_diag_dump  The syzbot report a crash:    Oops: general protection fault, probably for non-canonical address 0xfbd5a5d5a0000003: 0000 [#1] SMP KASAN NOPTI   KASAN: maybe wild-memory-access in range [0xdead4ead00000018-0xdead4ead0000001f]   CPU: 1 UID: 0 PID: 6949 Comm: syz.0.335 Not tainted syzkaller #0 PREEMPT(full)   Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025   RIP: 0010:smc_diag_msg_common_fill net/smc/smc_diag.c:44 [inline]   RIP: 0010:__smc_diag_dump.constprop.0+0x3ca/0x2550 net/smc/smc_diag.c:89   Call Trace:    <TASK>    smc_diag_dump_proto+0x26d/0x420 net/smc/smc_diag.c:217    smc_diag_dump+0x27/0x90 net/smc/smc_diag.c:234    netlink_dump+0x539/0xd30 net/netlink/af_netlink.c:2327    __netlink_dump_start+0x6d6/0x990 net/netlink/af_netlink.c:2442    netlink_dump_start include/linux/netlink.h:341 [inline]    smc_diag_handler_dump+0x1f9/0x240 net/smc/smc_diag.c:251    __sock_diag_cmd net/core/sock_diag.c:249 [inline]    sock_diag_rcv_msg+0x438/0x790 net/core/sock_diag.c:285    netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552    netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]    netlink_unicast+0x5a7/0x870 net/netlink/af_netlink.c:1346    netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896    sock_sendmsg_nosec net/socket.c:714 [inline]    __sock_sendmsg net/socket.c:729 [inline]    ____sys_sendmsg+0xa95/0xc70 net/socket.c:2614    ___sys_sendmsg+0x134/0x1d0 net/socket.c:2668    __sys_sendmsg+0x16d/0x220 net/socket.c:2700    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]    do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94    entry_SYSCALL_64_after_hwframe+0x77/0x7f    </TASK>  The process like this:                 (CPU1)              |             (CPU2)   ---------------------------------|-------------------------------   inet_create()                    |     // init clcsock to NULL        |     sk = sk_alloc()                |                                    |     // unexpectedly change clcsock |     inet_init_csk_locks()          |                                    |     // add sk to hash table        |     smc_inet_init_sock()           |       smc_sk_init()                |         smc_hash_sk()              |                                    | // traverse the hash table                                    | smc_diag_dump_proto                                    |   __smc_diag_dump()                                    |     // visit wrong clcsock                                    |     smc_diag_msg_common_fill()     // alloc clcsock               |     smc_create_clcsk               |       sock_create_kern             |  With CONFIG_DEBUG_LOCK_ALLOC=y, the smc->clcsock is unexpectedly changed in inet_init_csk_locks(). The INET_PROTOSW_ICSK flag is no need by smc, just remove it.  After removing the INET_PROTOSW_ICSK flag, this patch alse revert commit 6fd27ea183c2 ("net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC") to avoid casting smc_sock to inet_connection_sock.
CVE-2025-40359: In the Linux kernel, the following vulnerability has been resolved:  perf/x86/intel: Fix KASAN global-out-of-bounds warning  When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen.    ==================================================================   BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0   Read of size 4 at addr ffffffffb721d000 by task dtlb/9850    Call Trace:     kasan_report+0xb8/0xf0    cmt_latency_data+0x176/0x1b0    setup_arch_pebs_sample_data+0xf49/0x2560    intel_pmu_drain_arch_pebs+0x577/0xb00    handle_pmi_common+0x6c4/0xc80  The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF.          WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)  So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue.
CVE-2025-40360: In the Linux kernel, the following vulnerability has been resolved:  drm/sysfb: Do not dereference NULL pointer in plane reset  The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL.  v2: - fix typo in commit description (Javier)
CVE-2025-40362: In the Linux kernel, the following vulnerability has been resolved:  ceph: fix multifs mds auth caps issue  The mds auth caps check should also validate the fsname along with the associated caps. Not doing so would result in applying the mds auth caps of one fs on to the other fs in a multifs ceph cluster. The bug causes multiple issues w.r.t user authentication, following is one such example.  Steps to Reproduce (on vstart cluster): 1. Create two file systems in a cluster, say 'fsname1' and 'fsname2' 2. Authorize read only permission to the user 'client.usr' on fs 'fsname1'     $ceph fs authorize fsname1 client.usr / r 3. Authorize read and write permission to the same user 'client.usr' on fs 'fsname2'     $ceph fs authorize fsname2 client.usr / rw 4. Update the keyring     $ceph auth get client.usr >> ./keyring  With above permssions for the user 'client.usr', following is the expectation.   a. The 'client.usr' should be able to only read the contents      and not allowed to create or delete files on file system 'fsname1'.   b. The 'client.usr' should be able to read/write on file system 'fsname2'.  But, with this bug, the 'client.usr' is allowed to read/write on file system 'fsname1'. See below.  5. Mount the file system 'fsname1' with the user 'client.usr'      $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/ 6. Try creating a file on file system 'fsname1' with user 'client.usr'. This    should fail but passes with this bug.      $touch /kmnt_fsname1_usr/file1 7. Mount the file system 'fsname1' with the user 'client.admin' and create a    file.      $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin      $echo "data" > /kmnt_fsname1_admin/admin_file1 8. Try removing an existing file on file system 'fsname1' with the user    'client.usr'. This shoudn't succeed but succeeds with the bug.      $rm -f /kmnt_fsname1_usr/admin_file1  For more information, please take a look at the corresponding mds/fuse patch and tests added by looking into the tracker mentioned below.  v2: Fix a possible null dereference in doutc v3: Don't store fsname from mdsmap, validate against     ceph_mount_options's fsname and use it v4: Code refactor, better warning message and     fix possible compiler warning  [ Slava.Dubeyko: "fsname check failed" -> "fsname mismatch" ]
CVE-2025-68167: In the Linux kernel, the following vulnerability has been resolved:  gpiolib: fix invalid pointer access in debugfs  If the memory allocation in gpiolib_seq_start() fails, the s->private field remains uninitialized and is later dereferenced without checking in gpiolib_seq_stop(). Initialize s->private to NULL before calling kzalloc() and check it before dereferencing it.
CVE-2025-68168: In the Linux kernel, the following vulnerability has been resolved:  jfs: fix uninitialized waitqueue in transaction manager  The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems.  When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0.  This causes a 'non-static key' lockdep warning and system crash:   INFO: trying to register non-static key in txEnd  Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit().
CVE-2025-68169: In the Linux kernel, the following vulnerability has been resolved:  netpoll: Fix deadlock in memory allocation under spinlock  Fix a AA deadlock in refill_skbs() where memory allocation while holding skb_pool->lock can trigger a recursive lock acquisition attempt.  The deadlock scenario occurs when the system is under severe memory pressure:  1. refill_skbs() acquires skb_pool->lock (spinlock) 2. alloc_skb() is called while holding the lock 3. Memory allocator fails and calls slab_out_of_memory() 4. This triggers printk() for the OOM warning 5. The console output path calls netpoll_send_udp() 6. netpoll_send_udp() attempts to acquire the same skb_pool->lock 7. Deadlock: the lock is already held by the same CPU  Call stack:   refill_skbs()     spin_lock_irqsave(&skb_pool->lock)    <- lock acquired     __alloc_skb()       kmem_cache_alloc_node_noprof()         slab_out_of_memory()           printk()             console_flush_all()               netpoll_send_udp()                 skb_dequeue()                   spin_lock_irqsave(&skb_pool->lock)     <- deadlock attempt  This bug was exposed by commit 248f6571fd4c51 ("netpoll: Optimize skb refilling on critical path") which removed refill_skbs() from the critical path (where nested printk was being deferred), letting nested printk being called from inside refill_skbs()  Refactor refill_skbs() to never allocate memory while holding the spinlock.  Another possible solution to fix this problem is protecting the refill_skbs() from nested printks, basically calling printk_deferred_{enter,exit}() in refill_skbs(), then, any nested pr_warn() would be deferred.  I prefer this approach, given I _think_ it might be a good idea to move the alloc_skb() from GFP_ATOMIC to GFP_KERNEL in the future, so, having the alloc_skb() outside of the lock will be necessary step.  There is a possible TOCTOU issue when checking for the pool length, and queueing the new allocated skb, but, this is not an issue, given that an extra SKB in the pool is harmless and it will be eventually used.
CVE-2025-68170: In the Linux kernel, the following vulnerability has been resolved:  drm/radeon: Do not kfree() devres managed rdev  Since the allocation of the drivers main structure was changed to devm_drm_dev_alloc() rdev is managed by devres and we shouldn't be calling kfree() on it.  This fixes things exploding if the driver probe fails and devres cleans up the rdev after we already free'd it.  (cherry picked from commit 16c0681617b8a045773d4d87b6140002fa75b03b)
CVE-2025-68172: In the Linux kernel, the following vulnerability has been resolved:  crypto: aspeed - fix double free caused by devm  The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free.  Remove the manual clock cleanup in both aspeed_acry_probe()'s error path and aspeed_acry_remove().
CVE-2025-68176: In the Linux kernel, the following vulnerability has been resolved:  PCI: cadence: Check for the existence of cdns_pcie::ops before using it  cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops.  Hence, add a check to prevent NULL pointer dereference.  [mani: reworded subject and description]
CVE-2025-68177: In the Linux kernel, the following vulnerability has been resolved:  cpufreq/longhaul: handle NULL policy in longhaul_exit  longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic.  This patch adds a check using unlikely() and returns early if the policy is NULL.  Bugzilla: #219962
CVE-2025-68181: In the Linux kernel, the following vulnerability has been resolved:  drm/radeon: Remove calls to drm_put_dev()  Since the allocation of the drivers main structure was changed to devm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'd should be done by devres.  However, drm_put_dev() is still in the probe error and device remove paths. When the driver fails to probe warnings like the following are shown because devres is trying to drm_put_dev() after the driver already did it.  [    5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22 [    5.649605] ------------[ cut here ]------------ [    5.649607] refcount_t: underflow; use-after-free. [    5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110  (cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)
CVE-2025-68182: In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()  This code frees "link" by calling kfree_rcu(link, rcu_head) and then it dereferences "link" to get the "link->fw_id".  Save the "link->fw_id" first to avoid a potential use after free.
CVE-2025-68187: In the Linux kernel, the following vulnerability has been resolved:  net: mdio: Check regmap pointer returned by device_node_to_regmap()  The call to device_node_to_regmap() in airoha_mdio_probe() can return an ERR_PTR() if regmap initialization fails. Currently, the driver stores the pointer without validation, which could lead to a crash if it is later dereferenced.  Add an IS_ERR() check and return the corresponding error code to make the probe path more robust.
CVE-2025-68188: In the Linux kernel, the following vulnerability has been resolved:  tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()  Use RCU to avoid a pair of atomic operations and a potential UAF on dst_dev()->flags.
CVE-2025-68190: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()  kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries.  Return -ENOMEM on allocation failure to avoid the NULL dereference.
CVE-2025-68192: In the Linux kernel, the following vulnerability has been resolved:  net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup  Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks.  Initialize the MAC header to prevent such crashes.  This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface.  Example trace:      Internal error: Oops: 000000009600004f [#1] SMP     CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1     Hardware name: LS1028A RDB Board (DT)     pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)     pc : xfrm_input+0xde8/0x1318     lr : xfrm_input+0x61c/0x1318     sp : ffff800080003b20     Call trace:      xfrm_input+0xde8/0x1318      xfrm6_rcv+0x38/0x44      xfrm6_esp_rcv+0x48/0xa8      ip6_protocol_deliver_rcu+0x94/0x4b0      ip6_input_finish+0x44/0x70      ip6_input+0x44/0xc0      ipv6_rcv+0x6c/0x114      __netif_receive_skb_one_core+0x5c/0x8c      __netif_receive_skb+0x18/0x60      process_backlog+0x78/0x17c      __napi_poll+0x38/0x180      net_rx_action+0x168/0x2f0
CVE-2025-68193: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/guc: Add devm release action to safely tear down CT  When a buffer object (BO) is allocated with the XE_BO_FLAG_GGTT_INVALIDATE flag, the driver initiates TLB invalidation requests via the CTB mechanism while releasing the BO. However a premature release of the CTB BO can lead to system crashes, as observed in:  Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:h2g_write+0x2f3/0x7c0 [xe] Call Trace:  guc_ct_send_locked+0x8b/0x670 [xe]  xe_guc_ct_send_locked+0x19/0x60 [xe]  send_tlb_invalidation+0xb4/0x460 [xe]  xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe]  ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe]  ggtt_node_remove+0x110/0x140 [xe]  xe_ggtt_node_remove+0x40/0xa0 [xe]  xe_ggtt_remove_bo+0x87/0x250 [xe]  Introduce a devm-managed release action during xe_guc_ct_init() and xe_guc_ct_init_post_hwconfig() to ensure proper CTB disablement before resource deallocation, preventing the use-after-free scenario.
CVE-2025-68195: In the Linux kernel, the following vulnerability has been resolved:  x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcode  Running x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an out of bounds access.
CVE-2025-68197: In the Linux kernel, the following vulnerability has been resolved:  bnxt_en: Fix null pointer dereference in bnxt_bs_trace_check_wrap()  With older FW, we may get the ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER for FW trace data type that has not been initialized.  This will result in a crash in bnxt_bs_trace_type_wrap().  Add a guard to check for a valid magic_byte pointer before proceeding.
CVE-2025-68202: In the Linux kernel, the following vulnerability has been resolved:  sched_ext: Fix unsafe locking in the scx_dump_state()  For built with CONFIG_PREEMPT_RT=y kernels, the dump_lock will be converted sleepable spinlock and not disable-irq, so the following scenarios occur:  inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. irq_work/0/27 [HC0[0]:SC0[0]:HE1:SE1] takes: (&rq->__lock){?...}-{2:2}, at: raw_spin_rq_lock_nested+0x2b/0x40 {IN-HARDIRQ-W} state was registered at:    lock_acquire+0x1e1/0x510    _raw_spin_lock_nested+0x42/0x80    raw_spin_rq_lock_nested+0x2b/0x40    sched_tick+0xae/0x7b0    update_process_times+0x14c/0x1b0    tick_periodic+0x62/0x1f0    tick_handle_periodic+0x48/0xf0    timer_interrupt+0x55/0x80    __handle_irq_event_percpu+0x20a/0x5c0    handle_irq_event_percpu+0x18/0xc0    handle_irq_event+0xb5/0x150    handle_level_irq+0x220/0x460    __common_interrupt+0xa2/0x1e0    common_interrupt+0xb0/0xd0    asm_common_interrupt+0x2b/0x40    _raw_spin_unlock_irqrestore+0x45/0x80    __setup_irq+0xc34/0x1a30    request_threaded_irq+0x214/0x2f0    hpet_time_init+0x3e/0x60    x86_late_time_init+0x5b/0xb0    start_kernel+0x308/0x410    x86_64_start_reservations+0x1c/0x30    x86_64_start_kernel+0x96/0xa0    common_startup_64+0x13e/0x148   other info that might help us debug this:  Possible unsafe locking scenario:          CPU0         ----    lock(&rq->__lock);    <Interrupt>      lock(&rq->__lock);    *** DEADLOCK ***   stack backtrace:  CPU: 0 UID: 0 PID: 27 Comm: irq_work/0  Call Trace:   <TASK>   dump_stack_lvl+0x8c/0xd0   dump_stack+0x14/0x20   print_usage_bug+0x42e/0x690   mark_lock.part.44+0x867/0xa70   ? __pfx_mark_lock.part.44+0x10/0x10   ? string_nocheck+0x19c/0x310   ? number+0x739/0x9f0   ? __pfx_string_nocheck+0x10/0x10   ? __pfx_check_pointer+0x10/0x10   ? kvm_sched_clock_read+0x15/0x30   ? sched_clock_noinstr+0xd/0x20   ? local_clock_noinstr+0x1c/0xe0   __lock_acquire+0xc4b/0x62b0   ? __pfx_format_decode+0x10/0x10   ? __pfx_string+0x10/0x10   ? __pfx___lock_acquire+0x10/0x10   ? __pfx_vsnprintf+0x10/0x10   lock_acquire+0x1e1/0x510   ? raw_spin_rq_lock_nested+0x2b/0x40   ? __pfx_lock_acquire+0x10/0x10   ? dump_line+0x12e/0x270   ? raw_spin_rq_lock_nested+0x20/0x40   _raw_spin_lock_nested+0x42/0x80   ? raw_spin_rq_lock_nested+0x2b/0x40   raw_spin_rq_lock_nested+0x2b/0x40   scx_dump_state+0x3b3/0x1270   ? finish_task_switch+0x27e/0x840   scx_ops_error_irq_workfn+0x67/0x80   irq_work_single+0x113/0x260   irq_work_run_list.part.3+0x44/0x70   run_irq_workd+0x6b/0x90   ? __pfx_run_irq_workd+0x10/0x10   smpboot_thread_fn+0x529/0x870   ? __pfx_smpboot_thread_fn+0x10/0x10   kthread+0x305/0x3f0   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x40/0x70   ? __pfx_kthread+0x10/0x10   ret_from_fork_asm+0x1a/0x30   </TASK>  This commit therefore use rq_lock_irqsave/irqrestore() to replace rq_lock/unlock() in the scx_dump_state().
CVE-2025-68204: In the Linux kernel, the following vulnerability has been resolved:  pmdomain: arm: scmi: Fix genpd leak on provider registration failure  If of_genpd_add_provider_onecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpd_debug_add().  Add proper error handling to unwind the initialized domains before returning from probe to ensure all resources are correctly released on failure.  Example crash trace observed without this fix:    | Unable to handle kernel paging request at virtual address fffffffffffffc70   | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT   | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform   | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)   | pc : genpd_debug_add+0x2c/0x160   | lr : genpd_debug_init+0x74/0x98   | Call trace:   |  genpd_debug_add+0x2c/0x160 (P)   |  genpd_debug_init+0x74/0x98   |  do_one_initcall+0xd0/0x2d8   |  do_initcall_level+0xa0/0x140   |  do_initcalls+0x60/0xa8   |  do_basic_setup+0x28/0x40   |  kernel_init_freeable+0xe8/0x170   |  kernel_init+0x2c/0x140   |  ret_from_fork+0x10/0x20
CVE-2025-68205: In the Linux kernel, the following vulnerability has been resolved:  ALSA: hda/hdmi: Fix breakage at probing nvhdmi-mcp driver  After restructuring and splitting the HDMI codec driver code, each HDMI codec driver contains the own build_controls and build_pcms ops. A copy-n-paste error put the wrong entries for nvhdmi-mcp driver; both build_controls and build_pcms are swapped.  Unfortunately both callbacks have the very same form, and the compiler didn't complain it, either.  This resulted in a NULL dereference because the PCM instance hasn't been initialized at calling the build_controls callback.  Fix it by passing the proper entries.
CVE-2025-68207: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/guc: Synchronize Dead CT worker with unbind  Cancel and wait for any Dead CT worker to complete before continuing with device unbinding. Else the worker will end up using resources freed by the undind operation.  (cherry picked from commit 492671339114e376aaa38626d637a2751cdef263)
CVE-2025-68208: In the Linux kernel, the following vulnerability has been resolved:  bpf: account for current allocated stack depth in widen_imprecise_scalars()  The usage pattern for widen_imprecise_scalars() looks as follows:      prev_st = find_prev_entry(env, ...);     queued_st = push_stack(...);     widen_imprecise_scalars(env, prev_st, queued_st);  Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case:      def main():       for i in 1..2:         foo(i)        // same callsite, differnt param      def foo(i):       if i == 1:         use 128 bytes of stack       iterator based loop  Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds.