Back to CVE records
Not yet scoredPublished Oct 23, 2026

CVE-2026-98888arm64: kprobes: Allow reentering kprobes while single-stepping

Updated under an hour ago ()

Does this affect you?

It affects Linux. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

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").

CVSS
Not yet scored
Weakness (CWE)
Not given
Known exploited
Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days)
Not loaded for this CVE
Assigned by
Linux
NVD analysis
Received
Record last updated
Oct 26, 2026
First seen by InfoSec Signals
Oct 23, 2026

Affected products

Affected products
Linux Linux
linux:linux (from the name)
from 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 before bb0fe9121aa0824211aafa33c7d0151fd25ddb75; from 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 before f96a0606de6bcc8d937b80e6470fd7a174c17e26; 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 builds before 1f342b3e44c3035a837b53b217d816f7511c0d0a; from 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 before c8e84e292ed4cfc199824146da71bb4397b02a1f; from 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 before 68774caca799e9695db56d426c69acebd041c2ed; from 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 before a21bf9cb893126e8d9730995708d0be5eb167652; from 2dd0e8d2d2a157dbc83295a78336c2217110f2f8 before 23f851ac0078a908bf3422d6467ebc1db5828c46
CNA record

References

References

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.

Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.