CVE-2026-98888

arm64: kprobes: Allow reentering kprobes while single-stepping

State
Published
Severity
Not scored
Published
Oct 23, 2026
Updated
Oct 26, 2026
Reserved
Sep 25, 2026

Read the record on cve.org

Description

In the Linux kernel, the following vulnerability has been resolved:

arm64: kprobes: Allow reentering kprobes while single-stepping

A kprobe can be hit while another kprobe is in KPROBE_HIT_SS state. This can happen when tracing or perf code runs from the debug exception path while the first kprobe is preparing or executing its out-of-line single-step instruction.

Currently arm64 treats a kprobe hit in KPROBE_HIT_SS as unrecoverable, the same as a hit in KPROBE_REENTER. This is too strict. A hit in KPROBE_HIT_SS is still a one-level reentry and can be handled by saving the current kprobe state and setting up single-step for the new probe, just like reentry from KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE.

The truly unrecoverable case is hitting another kprobe while already in KPROBE_REENTER, because the reentry save area has already been consumed.

Move KPROBE_HIT_SS to the recoverable reentry cases and leave KPROBE_REENTER as the unrecoverable nested reentry case.

This change also requires saving saved_irqflag in struct prev_kprobe. When a nested kprobe calls kprobes_save_local_irqflag(), it overwrites kcb->saved_irqflag with the currently masked DAIF value, losing the outer kprobe's original DAIF state. Without this fix, when the outer kprobe's single-step finishes, kprobes_restore_local_irqflag() applies the wrong DAIF mask and leaves interrupts permanently disabled.

Extend struct prev_kprobe with a saved_irqflag field and save/restore it alongside kp and status. This ensures the outer kprobe's original interrupt state is preserved across reentry.

This mirrors the x86 fix in commit 6a5022a56ac3 ("kprobes/x86: Allow to handle reentered kprobe on single-stepping").

Scores

The record has no CVSS score.

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 to before bb0fe9121aa0824211aafa33c7d0151fd25ddb75Affected
  • 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 to before f96a0606de6bcc8d937b80e6470fd7a174c17e26Affected
  • 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 to before 1f342b3e44c3035a837b53b217d816f7511c0d0aAffected
  • 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 to before c8e84e292ed4cfc199824146da71bb4397b02a1fAffected
  • 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 to before 68774caca799e9695db56d426c69acebd041c2edAffected
  • 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 to before a21bf9cb893126e8d9730995708d0be5eb167652Affected
  • 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 to before 23f851ac0078a908bf3422d6467ebc1db5828c46Affected
LinuxLinux
  • 4.8Affected
  • before 4.8Not affected
  • 5.10.271 through 5.10.*Not affected
  • 5.15.222 through 5.15.*Not affected
  • 6.1.189 through 6.1.*Not affected
  • 6.6.158 through 6.6.*Not affected
  • 6.12.111 through 6.12.*Not affected
  • 6.18.53 through 6.18.*Not affected
  • 7.2 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.