AZL-112529: CVE-2026-99217 affecting package kernel 6.6.159.1-1
In the Linux kernel, the following vulnerability has been resolved:
fork: release the files of a failed fork after schedcancelfork()
Reorder copyprocess() cleanup so schedfork() taking scxforkrwsem scxprefork() is safe and isn't held around exiting files. Right now, a fork that fails while another thread closed the bpf link fd will deadlock against its own read side. It also blocks every fork on the system:
copyprocess() holds scxforkrwsem for read exitfiles() closefiles() filpclosesync() bpfscxunreg() kthreadflushwork() waits for the disable work scxrootdisable() percpudownwrite(&scxforkrwsem)
Simply release the child's files after schedcancelfork() dropped the lock. The task starts out as a copy of its parent so p->files points to the parent's table until copyfiles() replaces it. exitfiles() must not run for a fork that failed before that. Clear p->files up front so exitfiles() is a no-op for those and make copyfiles() set it explicitly for CLONEFILES.
Affected Software
Event History
Frequently Asked Questions
What conditions are needed to trigger the deadlock?
A fork must fail while another thread closes a BPF link file descriptor. The failure path can then hold scx_fork_rwsem while closing files, and BPF scheduler-class unregister work attempts to acquire that lock for write.
What is the practical impact on a system that hits this issue?
The deadlock blocks every fork on the system, not only the process involved in the failed fork. This can prevent new processes from being created until the condition is cleared or the system is recovered.
Does the issue require use of the BPF scheduler-class path?
Yes. The described lock cycle involves BPF scheduler-class unregister handling through bpf_scx_unreg() and the scx_fork_rwsem lock.