Linux kernel x86/kprobes: wrong return address when probing a CS-prefixed CALL crashes the host

UnscoredCVE-2026-98273Kernel, userspace & hypervisorcurated

Impact

int3_emulate_call() assumes a probed CALL is 5 bytes, but a CS-prefixed CALL (emitted for indirect-thunk retpoline sites) is 6 bytes, so single-step emulation builds a return address in the middle of the instruction. The CPU then decodes garbage and the kernel oopses - the report shows a page fault in __hrtimer_run_queues(). Anyone able to place a kprobe or eBPF kprobe at an arbitrary function offset can crash the host, and on a GPU node that drops every tenant on the box. This matters most where observability agents or privileged debugging tooling attach kprobes by offset on fleet nodes.

Who can reach it

Local user with kprobe/eBPF tracing privileges (CAP_BPF/CAP_PERFMON or root, or an unconfined observability agent). Not reachable by an unprivileged tenant pod without tracing capabilities.

What to do

Apply the stable fix that uses the decoded instruction length instead of CALL_INSN_SIZE. Kernel update and node reboot, so drain first. In the meantime, do not grant kprobe/eBPF tracing capabilities to tenant workloads and avoid offset-based probes inside functions on affected kernels. No CVSS score or distro advisory in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-98273 https://git.kernel.org/stable/c/a5f7a5bb3b7f28ba7e4fa246775b29a0e5537255 https://git.kernel.org/stable/c/d8c6a18c0552135cbf0c696c9019b2979d0862c9

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.