AEGLIX vulnerability intelligence
CVE-2026-98888
UNSCORED · Received
Published: 2026-10-23 · Updated: 2026-10-26 · Source: NVD
Stored catalog record
Source record retrieved 2026-10-28T10:20:50.400912+00:00. Scheduled imports handle updates; this page does not assert that the provider was queried just now.
Vulnerability overview
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").
Patch review priority
Assess exposure and vendor guidance
- No higher-priority signal is available in the current stored evidence.
FIRST EPSS: 0.19% · percentile 8.2 · score date 2026-10-27.
EPSS estimates probability of exploitation in the next 30 days. It does not measure your exposure or prove exploitation. The elevated threshold is 10%; CISA KEV takes precedence. About FIRST EPSS ↗
Severity and scoring
- CVSS score
- Not scored · UNSCORED
- CVSS version
- Not supplied
- CVSS vector
- Not supplied
- Weaknesses
- Not supplied
CVSS measures technical severity; it does not establish whether this vulnerability is being exploited in your environment.
Known exploitation and remediation
Not listed in the CISA catalog retrieved for this record. This does not establish that exploitation has not occurred.
Verify affected versions and patch availability in the vendor advisory before making changes.
Affected products and versions
NVD has not supplied affected-version configurations for this record. Check the vendor references below.
Advisories and references
- https://git.kernel.org/stable/c/1f342b3e44c3035a837b53b217d816f7511c0d0a
- https://git.kernel.org/stable/c/23f851ac0078a908bf3422d6467ebc1db5828c46
- https://git.kernel.org/stable/c/68774caca799e9695db56d426c69acebd041c2ed
- https://git.kernel.org/stable/c/a21bf9cb893126e8d9730995708d0be5eb167652
- https://git.kernel.org/stable/c/bb0fe9121aa0824211aafa33c7d0151fd25ddb75
- https://git.kernel.org/stable/c/c8e84e292ed4cfc199824146da71bb4397b02a1f
- https://git.kernel.org/stable/c/f96a0606de6bcc8d937b80e6470fd7a174c17e26