CVE-2026-99217
NoneCVSS
—
EPSS
0.2%
Published
Nov 2, 2026
CISA due date
—
Cloudanix analysis
A flaw in how the operating system creates new processes can cause the entire system to stop creating any new processes when certain low-level tracing features are used at the same time.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability is a deadlock in copy_process() cleanup ordering: a failing fork holds scx_fork_rwsem for read while exit_files() triggers bpf_scx_unreg() which attempts a percpu_down_write on the same lock, blocking all subsequent forks system-wide.
Why it matters to the business
Systems may experience complete denial of new process creation, halting application launches, service restarts, and container orchestration until the deadlock is cleared by reboot or manual intervention.
How an attack unfolds
An attacker triggers a concurrent fork failure (via resource exhaustion or crafted bpf link close) while another thread closes a bpf link fd; the resulting lock-order inversion deadlocks the scx_fork_rwsem and prevents any further fork operations.
How to fix it
Upgrade to a Linux kernel containing the fix that releases the child's files after sched_cancel_fork() and clears p->files early; apply the patch that reorders copy_process cleanup around scx_fork_rwsem.
How to confirm the fix worked
Confirm kernel source contains the reordered exit_files call after sched_cancel_fork and that p->files is cleared before any potential failure path; test by exercising concurrent bpf link close and failing forks.
Typical attack path
- attacker obtains local code execution or unprivileged user access
- attacker opens bpf link fd and triggers sched_fork path
- attacker forces a concurrent fork failure before copy_files() completes
- attacker closes the bpf link fd from another thread to invoke bpf_scx_unreg
- deadlock occurs on scx_fork_rwsem blocking all fork operations
How to detect it
Search kernel logs for hung-task or deadlock messages referencing scx_fork_rwsem or bpf_scx_unreg; look for processes stuck in copy_process or exit_files during high bpf activity.
What your security team should do
- Prioritize kernel upgrade on all systems running affected scheduler or bpf code paths within the next maintenance window
- Monitor for kernel oops or hung task warnings involving scx_fork_rwsem
- Restrict unprivileged bpf link creation until patched kernels are deployed
The record
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|