Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls Affecting kernel-zfcpdump package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL10-KERNELZFCPDUMP-21732811
- published27 Oct 2026
- disclosed23 Oct 2026
Introduced: 23 Oct 2026
NewCVE-2026-98888 (opens in a new tab)How to fix?
There is no fixed version for RHEL:10 kernel-zfcpdump.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump package and not the kernel-zfcpdump package as distributed by RHEL.
See How to fix? for RHEL:10 relevant fixed versions and status.
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").
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2559562
- https://access.redhat.com/security/cve/CVE-2026-98888
- 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