CVE-2026-58099: Memory safety bugs in kqueue copy-on-fork implementation
When copying knotes from a parent kqueue to a child, the copy code did not correctly exclude marker knotes (used internally to track list traversal position) before marking them as in-flux and releasing the kqueue lock. If another thread freed a marker while the lock was dropped, the subsequent in-flux decrement operated on freed memory.
An unprivileged local user may be able to exploit these races to escalate privileges.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
FreeBSD systems are exposed where an unprivileged local user can run code. The described impact is local privilege escalation; no remote attack path is stated.
What does an attacker need to exploit it?
An attacker needs local, unprivileged access and must trigger a race involving kqueue copy-on-fork activity and concurrent freeing of an internal marker knote. The issue depends on timing while the kqueue lock is released.