DF-2739 — linker_file_unload() veto-path refcount underflow → premature teardown → UAF

What

sys/kern/kern_linker.c:linker_file_unload(). When a module vetoes the unload (module_unload(mod) != 0), the function releases llf_lock and then unconditionally executes file->refs-- (kern_linker.c:517-518) — dropping the caller's reference even though the unload failed and the file stays live on linker_files. The reference count is driven to 0 on a live object.

Consequences (all deterministic, syscall-only):

1. kldstat shows refs=0 for a loaded file (observable in the run log).
2. A later kldload of a module that MODULE_DEPENDs on it bumps refs 0→1 (kern_linker.c:1636) — the dependent becomes the sole holder of a reference that was already consumed once.
3. The original user's kldunload then takes the full-teardown path (refs == 1, not the refs > 1 fast path) and frees the linker_file while the dependent's deps[] still points at it.
4. Unloading the dependent recurses into linker_file_unload(freed_file) (kern_linker.c:544-545): read of freed->refs, TAILQ_REMOVE on freed memory, indirect call through freed->ops — use-after-free read/write/indirect-call.

Reproduce (on the DragonFly guest, as root)

cd /tmp/kldtest
csh build.sh      # builds vetoa.ko, depb.ko, ./poc
./poc             # run.sh

Expected on a vulnerable kernel (decisive lines from run.log):

== step 2: ... kldunload(4) = -1 errno=16 (Device busy)
   after vetoed unload        vetoa.ko   : id=4 refs=0     <-- refs==0, file LIVE
== step 3: ... dep loaded; vetoa refs     vetoa.ko   : id=4 refs=1
== step 4: ... kldunload(4) = 0           <-- premature teardown under live dependent
   after second unload        vetoa.ko   : NOT LOADED
*** BUG REPRODUCED ... ***
== step 5: ... -> panic
panic: Bad link elm 0xfffff8008bb64280 next->prev != elm
linker_file_unload() at linker_file_unload+0x478
linker_file_unload() at linker_file_unload+0x478
linker_file_unload() at linker_file_unload+0x14e
sys_kldunload() at sys_kldunload+0x81

The two nested linker_file_unload frames are the dependency-unload recursion (kern_linker.c:545) operating on the freed object.

Fix

fix.diff — one-line removal of the erroneous file->refs-- on the veto path (the caller keeps its reference when the unload fails). Validated on a rebuilt kernel: see VERDICT.md.

Trigger privilege

kldload(2)/kldunload(2) are gated by caps_priv_check_self(SYSCAP_NOKLD) (kern_linker.c:794, :841) — the deterministic trigger requires root. The bug is a kernel-robustness / memory-corruption defect on the privileged kld management path, not an unprivileged escalation.

DF-2739 VERDICT — REPRODUCED (kernel memory corruption / UAF, panic proof)

Bottom line

The veto path in linker_file_unload() (sys/kern/kern_linker.c:514-520) drops the caller's reference when a module vetoes the unload. This is a refcount underflow on a live linker_file that deterministically leads to a premature full teardown underneath a live dependent module and then a use-after-free when the dependent is unloaded. Reproduced end-to-end on the stock INVARIANTS guest with nothing but kldload(2)/kldunload(2)/kldstat(2) syscalls and two purpose-built KLDs (vetoa.ko, depb.ko).

How it reproduces (baseline run, run.log + panic.txt)

Decisive console lines (panic.txt):

vetoa: MOD_UNLOAD vetoed -> EBUSY
vetoa: MOD_UNLOAD accepted
depb: MOD_UNLOAD accepted
panic: Bad link elm 0xfffff8008bb64280 next->prev != elm
cpuid = 0
linker_file_unload() at linker_file_unload+0x478
linker_file_unload() at linker_file_unload+0x478
linker_file_unload() at linker_file_unload+0x14e
sys_kldunload() at sys_kldunload+0x81

Primitive characterization

Freed object: struct linker_file (~200 bytes, M_LINKER kmalloc zone — the same zone used by link_elf's elf_file, pathname and symbol-table allocations, so zone grooming by the (privileged) attacker is straightforward). The UAF gives:

• write: file->refs-- on the freed chunk (fast path, :494-497) and TAILQ_REMOVE(&linker_files, file, link) (:540) — two pointer writes into the freed chunk plus list-head surgery;
• indirect call: file->ops->unload(file) (:556) and file->ops->lookup_set etc. — control flow through a pointer read from the freed chunk on non-INVARIANTS builds;
• read: strlen(lf->filename), lf->deps[] walk.

On the INVARIANTS guest the TAILQ invariant check converts this into an immediate panic (proof). On production (non-INVARIANTS) builds this is silent heap corruption fully controllable by the already-privileged caller.

Why it stops short of uid=0

The only trigger entry points are kldunload(2)/kldload(2), both gated by caps_priv_check_self(SYSCAP_NOKLD) (sys/kern/kern_linker.c:794, :841); there is no unprivileged path that reaches the veto branch (netgraph's auto-load paths are root-gated at ngc_attach, sys/netgraph7/socket/ng_socket.c:182). So the honest impact ceiling is: deterministic kernel UAF on the privileged kld management path — kernel robustness/memory-corruption, not an unprivileged escalation. (Hard blocker: privilege gate at :841, verified by tracing every linker_file_unload caller.)

Fix validation

fix.diff removes the erroneous file->refs-- (the caller keeps its reference when unload fails). Applied to the guest's /usr/src, kernel rebuilt with make -j6 nativekernel KERNCONF=X86_64_GENERIC + installkernel, guest rebooted into #1: Mon Aug 31 12:46:55 UTC 2026, exact same PoC re-run (run.fixed.log):

Bad behavior eliminated; both modules end cleanly loadable/unloadable (kldstat tail in run.fixed.log).

Cross-checks that rule out alternative explanations

• The userrefs handling in sys_kldunload (:853-856) is symmetric and not the cause: refs underflow is observable before any user accounting.
• MODULE_DEPEND refcounting itself is correct on both load and unload when no veto occurs (control runs without the veto: clean load/unload cycles).
• The panic backtrace's double linker_file_unload frame is exactly the dependency recursion at :544-545 — not an unrelated list bug.