CVE-2026-80688 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region.
[ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8
[ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000
[ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3
[ 25.661244] Oops [#1]
[ 25.662997] Modules linked in:
[ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY
[ 25.674669] Hardware name: Tenstorrent Blackhole (DT)
[ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20
[ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000
[ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30
[ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002
[ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000
[ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30
[ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0
[ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
[ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
[ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402
[ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000
[ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c
[ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc
[ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4
[ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18
[ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc
Drop __init from its signature so that this doesn't happen.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in the Linux kernel for RISC-V architectures involves a race condition between system initialization and memory reclamation, specifically within the function vec_check_unaligned_access_speed_all_cpus. This issue arises because the function is marked with the __init attribute, which designates it as code that can be freed after the kernel has finished booting to reclaim memory resources. However, this function executes within a kernel thread (kthread) and performs hardware probing via System Bus Interface calls to determine unaligned access speeds across all CPUs. The critical flaw lies in the assumption that such initialization tasks will complete before free_initmem() is invoked to unmapped the .init.text section. If the SBI call takes an unexpectedly long time due to system load, debug prints, or hardware latency, the kthread may still be executing when the kernel attempts to release its memory pages.
When the kernel proceeds with freeing initialization memory while this specific thread remains active in the freed region, a severe instruction page fault occurs. The processor attempts to fetch instructions from virtual addresses that have been unmapped and potentially reallocated for other purposes. As evidenced by the provided crash logs, the system encounters an unable to handle kernel paging request at a virtual address within the .init.text section. This results in an Oops event where the program counter points directly into the freed memory space of vec_check_unaligned_access_speed_all_cpus. The stack trace confirms that the execution flow originates from kthread and ret_from_fork_kernel, indicating that the thread was still running post-boot rather than terminating during early initialization as expected by the __init semantics.
From a technical classification perspective, this vulnerability aligns with CWE-416 Use After Free, specifically involving executable code regions. The kernel incorrectly assumes temporal isolation between the completion of initialization routines and the reclamation of their memory footprint. In RISC-V systems, where vector extensions and unaligned access performance are critical for runtime optimization, leaving such probes active ensures that the system can adapt to hardware capabilities dynamically. However, failing to account for asynchronous execution delays creates a stability risk that manifests as kernel panics or undefined behavior depending on what data overwrites the freed memory pages. This is not merely a denial of service but a potential pathway for code injection if an attacker can control the contents of the reclaimed memory before it is reused by legitimate kernel structures, although the primary immediate impact observed is system instability and crash.
The operational impact includes unpredictable system crashes during or shortly after boot sequences, particularly on systems with slower SBI implementations or those running under heavy initialization loads. This undermines system reliability and can prevent successful deployment of kernels in environments requiring high uptime guarantees. The vulnerability affects RISC-V based devices that rely on dynamic CPU feature detection at runtime. Mitigation requires modifying the function signature to remove the __init attribute, thereby ensuring the code remains resident in memory for the duration of its execution regardless of when free_initmem() is called. This change preserves system stability by preventing access to unmapped executable pages. Additionally, developers should review other kthreads performing hardware probing during boot to ensure they do not share this timing dependency with early memory reclamation processes. Aligning with ATT&CK techniques related to resource hijacking or execution flow manipulation highlights the importance of strict lifecycle management for kernel modules and initialization routines in operating system design.