kqueue: Avoid enqueuing an already-enqueued knote

knotes with a non-trivial f_copy implementation may be activated before
kqueue_fork_copy_knote() is finished.  In particular, it may be enqueued
at the time that kqueue_fork_copy_knote() calls knote_enqueue().  Guard
against this.

Add a test case which triggers the race.

Fix several other problems with the replication of knote state:
- Make sure only the KN_ACTIVE and KN_DISABLED status flags are
  inherited, the rest should not be copied.
- Ignore marker knotes.
- Ignore knotes for kqueues.  They cannot be safely copied into the
  child without more work, as kqueues are inherently local to a process;
  on fork, we need to ensure that such knotes are patched to reference
  the new kqueue, not the original.
- Try to keep knote state stable by holding the kqueue and knlist locks
  while copying.

Approved by:	so
Security:	FreeBSD-SA-26:50.kqueue
Security:	CVE-2026-58083
Reviewed by:	kib
Reported by:	Hazley Samsudin of GovTech CSG
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D58223

0 files changed, 0 insertions, 0 deletions