CVE-2026-98856

What it actually does

Incorrect overlap checks in x86 optkprobe arming skip disarmed probes, allowing an INT3 from a new probe to corrupt the final byte of an active probe's five-byte jump displacement and redirect execution to an invalid address.

Why it matters to the business

Kernel instability, crashes, or unintended control flow during tracing or debugging workloads on affected Linux systems, raising risk of service disruption or security boundary violations.

How an attack unfolds

An attacker with kprobe registration privileges creates and disarms a probe at an offset inside an optimized probe's jump range, then arms a third probe so that get_optimized_kprobe stops at the disarmed entry; the resulting partial overwrite leaves the original jump invalid and execution can be hijacked when the probe site is hit.

How to fix it

Update the Linux kernel to a version containing the commit that continues past disarmed and unprepared probes when checking optkprobe overlap.

How to confirm the fix worked

Inspect the kprobes.c source for the updated get_optimized_kprobe logic that skips disarmed probes, or exercise probe arming sequences in a test environment to confirm correct behavior.

Typical attack path

1. Obtain ability to register kprobes via perf or debugfs
2. Place and disarm a probe at A+2 inside an existing optimized probe at A
3. Arm a new probe at A+4 to trigger flawed overlap logic
4. Trigger execution at the corrupted site to achieve wrong-address jump

How to detect it

Review kernel logs and tracing events for optprobe arming failures or unexpected INT3 handling around probe sites; correlate with processes that register kprobes.

What your security team should do

• Prioritize kernel updates on systems that use kprobes or dynamic tracing
• Restrict unprivileged access to kprobe registration interfaces
• Monitor kernel mailing lists for related stable backports