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.
An unprivileged local user may be able to exploit these races to escalate privileges.
Project Subscriptions
No data.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Thu, 15 Oct 2026 06:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Memory safety bugs in kqueue copy-on-fork implementation | |
| Weaknesses | CWE-362 CWE-416 |
|
| References |
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: freebsd
Published:
Updated: 2026-10-15T06:31:18.042Z
Reserved: 2026-06-29T01:40:17.499Z
Link: CVE-2026-58099
No data.
Status : Awaiting Analysis
Published: 2026-10-15T07:18:02.373
Modified: 2026-10-15T16:17:41.437
Link: CVE-2026-58099
No data.
OpenCVE Enrichment
Updated: 2026-10-15T12:00:18Z