Shocking

I think I can do a fairly good imitation of what Theo does to folks
coming up with "I've found a local hole, the world is ending".  OTOH,
you can experiment yourself - it's _not_ hard to come up with those
in OpenBSD.  Let's see...  Ah, here we go - take fcntl(fd, F_SETLK, ...)
vs. close(fd) in another thread, while fcntl() has already done FREF()
and sits blocked in copyin().  close(2) gets to closef(), sees no
POSIX locks set (there's none - yet), sets FIF_WANTCLOSE and goes
to sleep until usecount drops to zero.  That won't happens until
FRELE() in fcntl(2).  So far, so good, but now closef() sees that
FHASLOCK is not set (no flock() locks on that one) and happily
proceeds to ->fo_close().  At that point you've got a lock hanging
off (e.g.) ->i_lockf, with neither VFS nor filesystem having any idea
that it's there.

Alternatively, have another task having the same opened file (e.g.
something that got that sucker from us via SCM_RIGHTS; whatever).
Then close(2) in question will miss the same lock, leaving it in
the list.  And struct file will live as long as you want it to live.
Now note that this lock has ->lf_id equal to address of struct proc
of the sucker that had created it.  Even if aforementioned sucker
is long gone *and* struct proc got reused.

Turning that into a local vulnerability is left as a clue filter.
RTFS(kern/{vfs_lockf.c,kern_descrip.c,vfs_syscalls.c}).  Have fun.
In the interests of disclosure, the source of the above has been
"OK, what kind of mess have I seen lately?  Let's see if they've got
something similar" followed by 15 minutes of RTFS and grep.