CVE-2026-98273 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
x86/kprobes: Fix crash when probing CS CALL instructions
When using eBPF to probe CS CALL instructions within a function, a crash can be triggered.
The eBPF tool probes offset 257 of the __hrtimer_run_queues() function:
<__hrtimer_run_queues+249>: nopl 0x0(%rax,%rax,1) <__hrtimer_run_queues+254>: mov %r14,%rdi <__hrtimer_run_queues+257>: cs call <__x86_indirect_thunk_r12> <__hrtimer_run_queues+263>: mov %eax,%r12d <__hrtimer_run_queues+266>: xchg %ax,%ax <__hrtimer_run_queues+268>: mov %r13,%rdi
Which triggers this crash:
BUG: unable to handle page fault for address: 00000000000f41c9 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI
CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P RIP: 0010:__hrtimer_run_queues+0x106/0x230
Note that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is at the 6th byte of the above CS CALL instruction. Since the CS CALL instruction occupies 6 bytes, the exception occurred in the middle of that call instruction.
The root cause is that when using eBPF tools to probe in the middle of a function, a kprobe with INT3 is used as the underlying implementation.
During single-step emulation of the original CALL instruction, int3_emulate_call() assumes that the probed CALL instruction is 5 bytes long. However, the actual CS-prefixed CALL instruction occupies 6 bytes, so it constructs an incorrect exception return address. When the CPU returns from the kprobe handler, the next instruction to be executed is at the address of the last byte of that CS CALL instruction. Coincidentally, starting from that address, the CPU fetches and decodes a completely different instruction, which ultimately triggers a kernel crash.
Fix the issue by using the actual instruction length obtained from the instruction decoder when constructing the exception return address, rather than relying on the hardcoded CALL_INSN_SIZE macro.
[ mingo: Refined the changelog ]
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel contains a critical vulnerability in the x86 kprobes subsystem that leads to system crashes when attempting to probe specific call instructions using eBPF tools. This issue specifically affects CS-prefixed CALL instructions, which are used for far calls or segment-based code execution on 32-bit and 64-bit architectures. The root cause lies in the emulation logic within int3_emulate_call(), where a hardcoded assumption about instruction length causes incorrect exception return address construction. When an eBPF probe is placed at offset 257 of the __hrtimer_run_queues() function, it targets a CS CALL instruction that occupies six bytes rather than the standard five bytes assumed by the emulator. This discrepancy results in the CPU attempting to execute from an invalid memory location after single-stepping through the probed instruction, triggering a page fault and subsequent kernel panic due to supervisor write access on a non-present page.
From a technical perspective, this vulnerability represents a classic case of improper assumption regarding variable-length x86 instructions. The kprobes framework relies on inserting INT3 breakpoints (opcode 0xCC) into the target code stream to trap execution flow for debugging and profiling purposes. Upon triggering an INT3 exception, the kernel's kprobe handler emulates the original instruction before resuming normal execution. For CALL instructions, this emulation involves calculating where the CPU should return after simulating the call operation. The flaw occurs because int3_emulate_call() uses a static macro called CALL_INSN_SIZE, which is defined as five bytes for near calls. However, CS-prefixed calls require an additional byte to specify the segment selector or other operand data, making them six bytes long. By ignoring the actual decoded instruction length and relying on this hardcoded value, the emulator calculates an incorrect return address that points into the middle of the original instruction stream rather than immediately following it.
The operational impact of this vulnerability is severe, as it can lead to immediate kernel crashes or unpredictable system behavior depending on what instructions reside at the incorrectly calculated memory addresses. In the reported case involving __hrtimer_run_queues(), a high-frequency timer management function used in real-time and general-purpose Linux kernels, such instability could disrupt critical timing operations and cause broader system degradation. The crash manifests as an Oops with error code 0x002 indicating supervisor write access to a non-present page, which halts the affected CPU core and potentially triggers kdump if configured for post-crash analysis. This affects any environment utilizing eBPF-based tracing tools like bpftrace or perf that attempt to probe functions containing these specific instruction patterns.
This vulnerability aligns with CWE-20: Improper Input Validation, as the kernel fails to correctly validate the length of the probed instruction before constructing its execution context state. It also relates to CWE-476: NULL Pointer Dereference in effect, since accessing invalid memory addresses often leads to such faults, though here it is specifically a page fault due to unmapped or protected pages being accessed incorrectly. From an ATT&CK perspective, this falls under T1059: Command and Scripting Interpreter via eBPF programs, as attackers could potentially exploit kprobe mechanisms for unauthorized code execution if they can trigger such crashes in controlled environments to bypass security controls or gain footholds through kernel exploitation techniques that rely on precise instruction boundary manipulation.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects int3_emulate_call() to use the actual instruction length obtained from the x86 instruction decoder rather than relying on static macros. System administrators should ensure their kernels are updated to versions containing this fix, particularly those running eBPF-heavy workloads or using advanced tracing tools for performance analysis and security monitoring. Additionally, developers implementing custom kprobes should be aware of variable-length instructions in x86 architecture and verify instruction boundaries before inserting breakpoints. Regular kernel updates and patch management remain the most effective defense against such low-level architectural flaws that can compromise system stability and integrity when triggered by legitimate administrative tools or malicious actors attempting to destabilize systems through precise memory access violations.