CVE-2026-98273
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's debugging tools could make the system crash if certain monitoring programs tried to watch specific internal function calls.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Kprobe single-step emulation for CS-prefixed CALL instructions uses a hardcoded 5-byte length instead of the decoder-reported 6-byte length, causing the emulated return address to land inside the instruction and trigger a kernel page fault during execution of subsequent bytes as unrelated opcodes.
Why it matters to the business
Systems running affected kernels can experience sudden kernel crashes and reboots when eBPF-based tracing or monitoring tools attempt to place probes on certain x86 CALL instructions, leading to unplanned downtime for workloads that rely on such observability tooling.
How an attack unfolds
An attacker or administrator loads an eBPF program that attaches a kprobe at an offset landing on a CS CALL instruction inside a kernel function such as __hrtimer_run_queues; the kprobe handler then performs single-step emulation using the wrong return address, causing the CPU to resume execution at an invalid location and fault.
How to fix it
Update to a Linux kernel containing the fix that replaces the hardcoded CALL_INSN_SIZE with the length returned by the instruction decoder; rebuild and reboot onto the corrected kernel image.
How to confirm the fix worked
Confirm the kernel source contains the corrected int3_emulate_call logic that uses insn.length, then verify that attaching an eBPF probe at the CS CALL offset no longer produces a page fault or Oops.
Typical attack path
- Identify a kernel function containing a CS-prefixed CALL instruction
- Attach an eBPF kprobe at an offset that splits the 6-byte instruction
- Trigger the probed code path so the kprobe handler runs
- Observe the incorrect return address calculation during int3_emulate_call
- Trigger kernel page fault and crash
How to detect it
Search kernel logs for Oops messages containing 'unable to handle page fault' near __hrtimer_run_queues or int3_emulate_call; review eBPF program load events and kprobe attachments around the publication date for unexpected tracing activity.
What your security team should do
- Prioritize kernel updates on systems that run eBPF tracing in production
- Audit eBPF programs that place kprobes near indirect call sites
- Test the updated kernel with representative tracing workloads before broad rollout
- Monitor for kernel Oops reports referencing kprobe or int3_emulate_call
The record
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 ]
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|