Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: m2m: Fix streaming cleanup on release<br /> <br /> If streamon/streamoff calls are imbalanced, such as when exiting an<br /> application with Ctrl+C when streaming, the m2m usage_count will never<br /> reach zero and the ISI channel won&amp;#39;t be freed. Besides from that, if the<br /> input line width is more than 2K, it will trigger a WARN_ON():<br /> <br /> [ 59.222120] ------------[ cut here ]------------<br /> [ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654<br /> [ 59.238569] Modules linked in: ap1302<br /> [ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT<br /> [ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT)<br /> [ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120<br /> [ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120<br /> [ 59.275047] sp : ffff8000848c3b40<br /> [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00<br /> [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001<br /> [ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780<br /> [ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000<br /> [ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c<br /> [ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> [ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30<br /> [ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420<br /> [ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000<br /> [ 59.349590] Call trace:<br /> [ 59.352025] mxc_isi_channel_chain+0xa4/0x120 (P)<br /> [ 59.356722] mxc_isi_m2m_streamon+0x160/0x20c<br /> [ 59.361072] v4l_streamon+0x24/0x30<br /> [ 59.364556] __video_do_ioctl+0x40c/0x4a0<br /> [ 59.368560] video_usercopy+0x2bc/0x690<br /> [ 59.372382] video_ioctl2+0x18/0x24<br /> [ 59.375857] v4l2_ioctl+0x40/0x60<br /> [ 59.379168] __arm64_sys_ioctl+0xac/0x104<br /> [ 59.383172] invoke_syscall+0x48/0x104<br /> [ 59.386916] el0_svc_common.constprop.0+0xc0/0xe0<br /> [ 59.391613] do_el0_svc+0x1c/0x28<br /> [ 59.394915] el0_svc+0x34/0xf4<br /> [ 59.397966] el0t_64_sync_handler+0xa0/0xe4<br /> [ 59.402143] el0t_64_sync+0x198/0x19c<br /> [ 59.405801] ---[ end trace 0000000000000000 ]---<br /> <br /> Address this issue by moving the streaming preparation and cleanup to<br /> the vb2 .prepare_streaming() and .unprepare_streaming() operations. This<br /> also simplifies the driver by allowing direct usage of the<br /> v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Check GuC running state before deregistering exec queue<br /> <br /> In normal operation, a registered exec queue is disabled and<br /> deregistered through the GuC, and freed only after the GuC confirms<br /> completion. However, if the driver is forced to unbind while the exec<br /> queue is still running, the user may call exec_destroy() after the GuC<br /> has already been stopped and CT communication disabled.<br /> <br /> In this case, the driver cannot receive a response from the GuC,<br /> preventing proper cleanup of exec queue resources. Fix this by directly<br /> releasing the resources when GuC is not running.<br /> <br /> Here is the failure dmesg log:<br /> "<br /> [ 468.089581] ---[ end trace 0000000000000000 ]---<br /> [ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)<br /> [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535<br /> [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1<br /> [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1)<br /> [ 468.092716] ------------[ cut here ]------------<br /> [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]<br /> "<br /> <br /> v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled().<br /> As CT may go down and come back during VF migration.<br /> <br /> (cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: No support of struct argument in trampoline programs<br /> <br /> The current implementation does not support struct argument. This causes<br /> a oops when running bpf selftest:<br /> <br /> $ ./test_progs -a tracing_struct<br /> Oops[#1]:<br /> CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938<br /> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:<br /> rcu: 1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801<br /> rcu: (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)<br /> Sending NMI from CPU 0 to CPUs 1:<br /> rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) -&gt;state=0x0 -&gt;cpu=2<br /> rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.<br /> rcu: RCU grace-period kthread stack dump:<br /> task:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x00000800<br /> Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680<br /> 9000000085d88000 0000000000000000 0000000000000040 9000000087159350<br /> 9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005<br /> 00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004<br /> 9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e<br /> 00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350<br /> 900000008715bf98 0000000000000005 9000000087036000 900000008704a000<br /> 9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0<br /> 00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000<br /> 9000000007002150 00000000ffff355b 9000000084615480 0000000007000002<br /> ...<br /> Call Trace:<br /> [] __schedule+0x410/0x1520<br /> [] schedule+0x34/0x190<br /> [] schedule_timeout+0x98/0x140<br /> [] rcu_gp_fqs_loop+0x5f8/0x868<br /> [] rcu_gp_kthread+0x260/0x2e0<br /> [] kthread+0x144/0x238<br /> [] ret_from_kernel_thread+0x28/0xc8<br /> [] ret_from_kernel_thread_asm+0xc/0x88<br /> <br /> rcu: Stack dump where RCU GP kthread last ran:<br /> Sending NMI from CPU 0 to CPUs 2:<br /> NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4<br /> <br /> Reject it for now.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix bootup splat with separate_gpu_drm modparam<br /> <br /> The drm_gem_for_each_gpuvm_bo() call from lookup_vma() accesses<br /> drm_gem_obj.gpuva.list, which is not initialized when the drm driver<br /> does not support DRIVER_GEM_GPUVA feature. Enable it for msm_kms<br /> drm driver to fix the splat seen when msm.separate_gpu_drm=1 modparam<br /> is set:<br /> <br /> [ 9.506020] Unable to handle kernel paging request at virtual address fffffffffffffff0<br /> [ 9.523160] Mem abort info:<br /> [ 9.523161] ESR = 0x0000000096000006<br /> [ 9.523163] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 9.523165] SET = 0, FnV = 0<br /> [ 9.523166] EA = 0, S1PTW = 0<br /> [ 9.523167] FSC = 0x06: level 2 translation fault<br /> [ 9.523169] Data abort info:<br /> [ 9.523170] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000<br /> [ 9.523171] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 9.523172] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 9.523174] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000ad370f000<br /> [ 9.523176] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000ad4787403, pud=0000000ad4788403, pmd=0000000000000000<br /> [ 9.523184] Internal error: Oops: 0000000096000006 [#1] SMP<br /> [ 9.592968] CPU: 9 UID: 0 PID: 448 Comm: (udev-worker) Not tainted 6.17.0-rc4-assorted-fix-00005-g0e9bb53a2282-dirty #3 PREEMPT<br /> [ 9.592970] Hardware name: Qualcomm CRD, BIOS 6.0.240718.BOOT.MXF.2.4-00515-HAMOA-1 07/18/2024<br /> [ 9.592971] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 9.592973] pc : lookup_vma+0x28/0xe0 [msm]<br /> [ 9.592996] lr : get_vma_locked+0x2c/0x128 [msm]<br /> [ 9.763632] sp : ffff800082dab460<br /> [ 9.763666] Call trace:<br /> [ 9.763668] lookup_vma+0x28/0xe0 [msm] (P)<br /> [ 9.763688] get_vma_locked+0x2c/0x128 [msm]<br /> [ 9.763706] msm_gem_get_and_pin_iova_range+0x68/0x11c [msm]<br /> [ 9.763723] msm_gem_get_and_pin_iova+0x18/0x24 [msm]<br /> [ 9.763740] msm_fbdev_driver_fbdev_probe+0xd0/0x258 [msm]<br /> [ 9.763760] __drm_fb_helper_initial_config_and_unlock+0x288/0x528 [drm_kms_helper]<br /> [ 9.763771] drm_fb_helper_initial_config+0x44/0x54 [drm_kms_helper]<br /> [ 9.763779] drm_fbdev_client_hotplug+0x84/0xd4 [drm_client_lib]<br /> [ 9.763782] drm_client_register+0x58/0x9c [drm]<br /> [ 9.763806] drm_fbdev_client_setup+0xe8/0xcf0 [drm_client_lib]<br /> [ 9.763809] drm_client_setup+0xb4/0xd8 [drm_client_lib]<br /> [ 9.763811] msm_drm_kms_post_init+0x2c/0x3c [msm]<br /> [ 9.763830] msm_drm_init+0x1a8/0x22c [msm]<br /> [ 9.763848] msm_drm_bind+0x30/0x3c [msm]<br /> [ 9.919273] try_to_bring_up_aggregate_device+0x168/0x1d4<br /> [ 9.919283] __component_add+0xa4/0x170<br /> [ 9.919286] component_add+0x14/0x20<br /> [ 9.919288] msm_dp_display_probe_tail+0x4c/0xac [msm]<br /> [ 9.919315] msm_dp_auxbus_done_probe+0x14/0x20 [msm]<br /> [ 9.919335] dp_aux_ep_probe+0x4c/0xf0 [drm_dp_aux_bus]<br /> [ 9.919341] really_probe+0xbc/0x298<br /> [ 9.919345] __driver_probe_device+0x78/0x12c<br /> [ 9.919348] driver_probe_device+0x40/0x160<br /> [ 9.919350] __driver_attach+0x94/0x19c<br /> [ 9.919353] bus_for_each_dev+0x74/0xd4<br /> [ 9.919355] driver_attach+0x24/0x30<br /> [ 9.919358] bus_add_driver+0xe4/0x208<br /> [ 9.919360] driver_register+0x60/0x128<br /> [ 9.919363] __dp_aux_dp_driver_register+0x24/0x30 [drm_dp_aux_bus]<br /> [ 9.919365] atana33xc20_init+0x20/0x1000 [panel_samsung_atna33xc20]<br /> [ 9.919370] do_one_initcall+0x6c/0x1b0<br /> [ 9.919374] do_init_module+0x58/0x234<br /> [ 9.919377] load_module+0x19cc/0x1bd4<br /> [ 9.919380] init_module_from_file+0x84/0xc4<br /> [ 9.919382] __arm64_sys_finit_module+0x1b8/0x2cc<br /> [ 9.919384] invoke_syscall+0x48/0x110<br /> [ 9.919389] el0_svc_common.constprop.0+0xc8/0xe8<br /> [ 9.919393] do_el0_svc+0x20/0x2c<br /> [ 9.919396] el0_svc+0x34/0xf0<br /> [ 9.919401] el0t_64_sync_handler+0xa0/0xe4<br /> [ 9.919403] el0t_64_sync+0x198/0x19c<br /> [ 9.919407] Code: eb0000bf 54000480 d100a003 aa0303e2 (f8418c44)<br /> [ 9.919410] ---[ end trace 0000000000000000 ]---<br /> <br /> Patchwork: https://patchwork.freedesktop.org/pa<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: hugetlb: avoid soft lockup when mprotect to large memory area<br /> <br /> When calling mprotect() to a large hugetlb memory area in our customer&amp;#39;s<br /> workload (~300GB hugetlb memory), soft lockup was observed:<br /> <br /> watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]<br /> <br /> CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7<br /> Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025<br /> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mte_clear_page_tags+0x14/0x24<br /> lr : mte_sync_tags+0x1c0/0x240<br /> sp : ffff80003150bb80<br /> x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000<br /> x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458<br /> x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000<br /> x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000<br /> x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000<br /> <br /> Call trace:<br />   mte_clear_page_tags+0x14/0x24<br />   set_huge_pte_at+0x25c/0x280<br />   hugetlb_change_protection+0x220/0x430<br />   change_protection+0x5c/0x8c<br />   mprotect_fixup+0x10c/0x294<br />   do_mprotect_pkey.constprop.0+0x2e0/0x3d4<br />   __arm64_sys_mprotect+0x24/0x44<br />   invoke_syscall+0x50/0x160<br />   el0_svc_common+0x48/0x144<br />   do_el0_svc+0x30/0xe0<br />   el0_svc+0x30/0xf0<br />   el0t_64_sync_handler+0xc4/0x148<br />   el0t_64_sync+0x1a4/0x1a8<br /> <br /> Soft lockup is not triggered with THP or base page because there is<br /> cond_resched() called for each PMD size.<br /> <br /> Although the soft lockup was triggered by MTE, it should be not MTE<br /> specific. The other processing which takes long time in the loop may<br /> trigger soft lockup too.<br /> <br /> So add cond_resched() for hugetlb to avoid soft lockup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping<br /> <br /> When an invalid value is passed via quirk option, currently<br /> bytcr_rt5640 driver only shows an error message but leaves as is.<br /> This may lead to unepxected results like OOB access.<br /> <br /> This patch corrects the input mapping to the certain default value if<br /> an invalid value is passed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: debugfs: Fix legacy mode page table dump logic<br /> <br /> In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR<br /> maybe uninitialized or zero in that case and may cause oops like:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xf00087d3f000f000: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014<br /> RIP: 0010:pgtable_walk_level+0x98/0x150<br /> RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206<br /> RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e<br /> RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000<br /> RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002<br /> R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000<br /> R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98<br /> FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> pgtable_walk_level+0x88/0x150<br /> domain_translation_struct_show.isra.0+0x2d9/0x300<br /> dev_domain_translation_struct_show+0x20/0x40<br /> seq_read_iter+0x12d/0x490<br /> ...<br /> <br /> Avoid walking the page table if TT is not 00b or 01b.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()<br /> <br /> The drv-&gt;sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which<br /> would lead to a error pointer dereference. Use IS_ERR_OR_NULL() to check<br /> that the pointer is valid.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller<br /> <br /> When loading the i10nm_edac driver on some Intel Granite Rapids servers,<br /> a call trace may appear as follows:<br /> <br /> UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16<br /> shift exponent -66 is negative<br /> ...<br /> __ubsan_handle_shift_out_of_bounds+0x1e3/0x390<br /> skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]<br /> i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]<br /> skx_register_mci+0x159/0x220 [skx_edac_common]<br /> i10nm_init+0xcb0/0x1ff0 [i10nm_edac]<br /> ...<br /> <br /> This occurs because some BIOS may disable a memory controller if there<br /> aren&amp;#39;t any memory DIMMs populated on this memory controller. The DIMMMTR<br /> register of this disabled memory controller contains the invalid value<br /> ~0, resulting in the call trace above.<br /> <br /> Fix this call trace by skipping DIMM enumeration on a disabled memory<br /> controller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: use RCU in ip6_output()<br /> <br /> Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent<br /> possible UAF.<br /> <br /> We can remove rcu_read_lock()/rcu_read_unlock() pairs<br /> from ip6_finish_output2().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT<br /> <br /> snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts<br /> via spin_lock_irq(). This also implicitly disables the handling of<br /> softirqs such as TIMER_SOFTIRQ.<br /> On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not<br /> disable them. That means a timer can be invoked during spin_lock_irq()<br /> on the same CPU. Due to synchronisations reasons local_bh_disable() has<br /> a per-CPU lock named softirq_ctrl.lock which synchronizes individual<br /> softirq against each other.<br /> syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is<br /> acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This<br /> is a possible deadlock.<br /> <br /> The softirq_ctrl.lock can not be made part of spin_lock_irq() as this<br /> would lead to too much synchronisation against individual threads on the<br /> system. To avoid the possible deadlock, softirqs must be manually<br /> disabled before the lock is acquired.<br /> <br /> Disable softirqs before the lock is acquired on PREEMPT_RT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: dont report verifier bug for missing bpf_scc_visit on speculative path<br /> <br /> Syzbot generated a program that triggers a verifier_bug() call in<br /> maybe_exit_scc(). maybe_exit_scc() assumes that, when called for a<br /> state with insn_idx in some SCC, there should be an instance of struct<br /> bpf_scc_visit allocated for that SCC. Turns out the assumption does<br /> not hold for speculative execution paths. See example in the next<br /> patch.<br /> <br /> maybe_scc_exit() is called from update_branch_counts() for states that<br /> reach branch count of zero, meaning that path exploration for a<br /> particular path is finished. Path exploration can finish in one of<br /> three ways:<br /> a. Verification error is found. In this case, update_branch_counts()<br /> is called only for non-speculative paths.<br /> b. Top level BPF_EXIT is reached. Such instructions are never a part of<br /> an SCC, so compute_scc_callchain() in maybe_scc_exit() will return<br /> false, and maybe_scc_exit() will return early.<br /> c. A checkpoint is reached and matched. Checkpoints are created by<br /> is_state_visited(), which calls maybe_enter_scc(), which allocates<br /> bpf_scc_visit instances for checkpoints within SCCs.<br /> <br /> Hence, for non-speculative symbolic execution paths, the assumption<br /> still holds: if maybe_scc_exit() is called for a state within an SCC,<br /> bpf_scc_visit instance must exist.<br /> <br /> This patch removes the verifier_bug() call for speculative paths.