DF-2984 — syscall_deregister() writes sysent[*offset] through an unvalidated index with an unvalidated value (live-slot destruction → unprivileged persistent kernel panic; arbitrary-index 24-byte zero write)

Where

• Sink: sys/kern/kern_syscalls.c:72-78 (syscall_deregister)
• Reachable via: sys/kern/kern_module.c:110-116 (MOD_LOAD-failure rollback calls module_unload() → MOD_UNLOAD) → sys/kern/kern_syscalls.c:99-106
• Dispatch of the corrupted slot: sys/platform/pc64/x86_64/trap.c:1235,1285 (narg = callp->sy_narg … (*callp->sy_call)(...), no NULL check)

What (one paragraph)

syscall_deregister() does if (*offset) sysent[*offset] = *old_sysent; — no bounds check on *offset (note NO_SYSCALL == -1, which passes the truthiness test) and no check that *offset/*old_sysent were ever established by a successful syscall_register(). When a KLD's MOD_LOAD fails, module_register_init() (kern_module.c:112) dispatches MOD_UNLOAD as a rollback — which lands in syscall_module_handler() and calls syscall_deregister() even though registration never succeeded. Three concrete variants:

1. EEXIST (two legitimate fixed-offset modules both claiming reserved slot N, e.g. 210): the failed loader's rollback executes sysent[N] = { sy_narg=0, sy_rsize=0, sy_call=NULL, sy_abort=NULL }, destroying the live syscall of the first module. kldload(2) of the second module still reports success (SYSINIT void return — the DF-2936 class). From then on, any unprivileged user invoking syscall(N) performs a kernel-mode call through a NULL function pointer → deterministic, reboot-only-fixable kernel panic.
2. EINVAL (fixed offset outside [0, SYS_MAXSYSCALL)): rollback executes sysent[N] = zeros at sysent + N*24 for author-chosen N ∈ (-2³¹, 2³¹) — semi-arbitrary kernel-memory zero write (24 bytes).
3. ENFILE (all ten dynamic slots 210-219 busy): *offset stays NO_SYSCALL == -1 → sysent[-1] = zeros, a 24-byte OOB write below the array in kernel .data.

Contents

• modA/ — legitimate KLD claiming fixed slot 210 (syscall returns 4242)
• modB/ — legitimate KLD also claiming fixed slot 210 (EEXIST trigger)
• modC/ — KLD with fixed offset 99999 (EINVAL / OOB-index trigger)
• call210.c — unprivileged trigger (syscall(210))
• build.sh / run.sh — exact commands
• build.log / run.log — baseline (buggy kernel #0) run
• panic.txt — serial-console capture of the unprivileged NULL-call panic
• run.fix.log — patched-kernel (#1) validation
• fix.diff — the fix (bounds re-validation + registered gate)
• verdict.json / manifest.json

Build

As root in the guest (proven KLD pattern, KERNBUILDDIR /usr/obj/usr/src/sys/X86_64_GENERIC):

sh build.sh

Run (baseline — expect panic)

sh run.sh                        # root: kldload A; unpriv live check; kldload B
/tmp/df2984/call210              # as ANY user: kernel panic, RIP=0

Success criterion (bug present):

1. kldload ./modA/dfpoca.ko → rc=0; unprivileged call210 → 4242
2. kldload ./modB/dfpocb.ko → rc=0 and dmesg module_register_init: MOD_LOAD (dfpocb, …) error 17
3. unprivileged call210 → Fatal trap 12: page fault while in kernel mode, fault virtual address = 0x0, instruction pointer = 0x8:0x0, process = call210 (uid 1001)

Run (patched — fix.diff applied, kernel #1)

Same steps: kldload B still logs error 17 and still returns rc=0 (the success-reporting bug is DF-2936's, unchanged), but the live slot is NOT touched: unprivileged call210 keeps returning 4242, and loading modC (out-of-range offset) writes nothing (guest healthy).

Impact ceiling (why panic, not uid0, for the unprivileged user)

The written value (old_sysent) is the module's static initializer — {0,0,NULL,NULL} for any stock-macro/hand-rolled module — so the state an unprivileged attacker can reach is a NULL sy_call (panic) or an ENOSYS-ish stub, never a controlled non-zero pointer. Presetting old_sysent.sy_call to an arbitrary kernel address requires authoring the module — which requires root (kldload → caps_priv_check_self (SYSCAP_NOKLD), kern_linker.c:794), i.e. no additional power. Variants 2/3 (corruption writes) are root-timed. Ceiling for uid≠0: persistent DoS.

DF-2984 VERDICT — reproduced (panic, unprivileged persistent) / fix validated (fixed)

Baseline (stock INVARIANTS kernel #0, Thu Jul 2 06:02:54 UTC 2026)

Full chain executed and captured (run.log, panic.txt, run.modc.log):

1. kldload ./modA/dfpoca.ko → rc=0. Module A is a legitimate, stock-pattern KLD: syscall_module_data + DECLARE_MODULE, fixed offset 210. Slot 210 goes live (syscall(210) == 4242).
2. kldload ./modB/dfpocb.ko → rc=0 (kldload "succeeds") while dmesg shows module_register_init: MOD_LOAD (dfpocb, ffffffff806826c0, 0xffffffff82601080) error 17 — EEXIST from syscall_register() (sys/kern/kern_syscalls.c:64-65, slot 210 no longer holds sys_lkmnosys). The rollback then fires: kern_module.c:112 module_unload(mod) → MOD_EVENT(mod, MOD_UNLOAD) → syscall_module_handler (kern_syscalls.c:99-106, chainevh NULL) → syscall_deregister(&210, &{0,0,NULL,NULL}) → sysent[210] = {0,0,NULL,NULL} (kern_syscalls.c:75-76). The LIVE slot belonging to module A is destroyed.
3. Unprivileged trigger (uid 1001, call210): ssh session hung (timeout), vm.sh status ⇒ down. Serial console (panic.txt):

Fatal user address access from kernel mode from call210 at 0000000000000000 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 instruction pointer = 0x8:0x0 current process = 978 (call210)

RIP=0 — the NULL sy_call written by syscall_deregister was invoked by trap.c:1285. Deterministic (every subsequent syscall(210) panics until reboot).

4. EINVAL variant (run.modc.log): kldload ./modC/dfpocc.ko (fixed offset 99999) → MOD_LOAD (dfpocc, …) error 22, rc=0, and the same sink executed sysent[99999] = zeros — silent this boot (the write lands ~2.3 MB past the table in already-zero kernel .bss), proving the arbitrary-index write reaches execution. (The identical sink produced the visible panic in step 2-3.)

Exploitability ceiling (adversarial assessment)

• For an unprivileged user the reachable corrupted state is exactly {sy_narg=0, sy_rsize=0, sy_call=NULL, sy_abort=NULL}: the value comes from the module's static initializer (the SYSCALL_MODULE macro's {0,0,NULL,NULL}), not from attacker input → NULL-call → panic. No controlled non-zero pointer, no data write, no info leak via this state.
• Controlling the written value (old_sysent.sy_call = arbitrary kernel address → the classic fake-syscall-call primitive with user-influenced sysmsg/args) requires authoring struct syscall_module_data — i.e. kldload, which requires root (caps_priv_check_self(SYSCAP_NOKLD), kern_linker.c:794; securelevel gated). Root already owns the machine.
• The index (variant 2/3 OOB writes) is likewise root-chosen.
• Conclusion: unprivileged impact = persistent local kernel panic (DoS); corruption primitives are real kernel-memory writes but root-gated. Severity Medium, bucket memcorrupt (unvalidated write into the global dispatch table), CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:H (≈5.5).

Fix validation (kernel #1, fix.diff applied in-guest, make nativekernel)

run.fix.log, kernel #1: Fri Sep 4 17:32:24 UTC 2026:

• kldload modA → rc=0; unprivileged call210 → 4242 (live).
• kldload modB → rc=0 and dmesg MOD_LOAD (dfpocb, …) error 17 (unchanged — failure still occurs, and kldload still mis-reports success, which is DF-2936's separate defect) — but the rollback now takes the registered == 0 path: no deregister, no write.
• Unprivileged call210 → survived: syscall(210) returned 4242 — the exact input that panicked kernel #0 is harmless on kernel #1.
• kldload modC (offset 99999) → MOD_LOAD (dfpocc, …) error 22, guest healthy (no OOB write; bounds check would return EINVAL anyway).
• Final call210 → 4242, vm.sh status ⇒ up.

fix_status = fixed (baseline behavior gone; no regression visible).

Honest notes

• The stock SYSCALL_MODULE macro is bit-rotted in this tree (its {0, NULL} old_sysent initializer fails -Werror against the 4-field struct sysent; zero in-tree users remain — rg syscall_register over sys/ shows only kern_syscalls.c). The PoC hand-rolls exactly what the macro would emit, which is the documented way KLDs reach syscall_module_handler. The kernel-side sink is unchanged by the macro's rot.
• The trigger modules are not buggy and contain nothing malicious — they are the standard registration pattern with two products claiming the same reserved number (210). No malformed structures, no crafted values: the corruption is purely kernel-side contract violation.
• Guest reset to clean-source snapshot after validation (vm.sh reset with-src), guest_dirty = 0.