DF-5011 — dimm(4) dimm_mod_unload() drains references it does not own → UAF/panic

Kernel module API defect in sys/dev/misc/dimm/dimm.c, demonstrated end-to-end on the QEMU guest: kldunload dimm while any KPI user still holds a dimm_softc reference silently drains the user's reference count and kfrees the live object; the user's next call into the dimm KPI (destroy, or an ECC/thermal sensor update) is a use-after-free into freed heap / unmapped module text — proven kernel panic (Fatal trap 12).

Files

• drainpoc.c — PoC kernel module source (mirrors ecc_e3.c: uses the dimm KPI without MODULE_DEPEND).
• build.sh — exact module build recipe (3 variants + fixed dimm.ko).
• run.sh — baseline reproduction (bug → drain → panic).
• run-control.sh — control: same module WITH MODULE_DEPEND (protected).
• run-fix.sh — fix validation with fix.diff-patched dimm.ko.
• build.log — compiler output (final successful builds).
• run.log — baseline transcript (drain + panic, full serial console).
• run.2.log — control transcript.
• run.3.log — fix-validation transcript.
• panic.txt — kernel panic from the guest serial console.
• env.txt — guest environment.
• fix.diff — git-apply-able fix against sys/dev/misc/dimm/dimm.c.

Precondition (important)

dimm_mod_unload() only runs when dimm is a loadable module. The stock X86_64_GENERIC kernel compiles dimm in (device dimm, sys/config/X86_64_GENERIC:189), where MOD_UNLOAD never runs. The bug is reachable on kernels built without device dimm where dimm.ko is pulled in by memtemp_e5/ecc_e5/ecc_e3 modules (this is exactly what /boot/kernel/dimm.ko being shipped is for). For the PoC the guest kernel was rebuilt without device dimm:

# in guest (DragonFly 6.5-DEVELOPMENT, /usr/src present):
sed -i '' -e '189s/^/#/' /usr/src/sys/config/X86_64_GENERIC   # device dimm
sed -i '' -e '191s/^/#/' /usr/src/sys/config/X86_64_GENERIC   # device ecc
sed -i '' -e '193s/^/#/' /usr/src/sys/config/X86_64_GENERIC   # device memtemp
cd /usr/src && make -j6 nativekernel KERNCONF=X86_64_GENERIC && \
    make installkernel KERNCONF=X86_64_GENERIC && shutdown -r now

(ecc/memtemp must go too — they reference dimm_* symbols at link time.)

Build

See build.sh. Three PoC module variants are produced from drainpoc.c by sed (the module name must be baked in; DECLARE_MODULE's internal ## pasting defeats macro-renaming, and CFLAGS+= in a kmod Makefile does not reach the compiler):

• drainpoc.ko — module drainpoc, NO MODULE_DEPEND(dimm) (bug path)
• deppoc.ko — module deppoc, WITH MODULE_DEPEND(dimm,1,1,1) (control)
• pocfix.ko — module pocfix, NO dep (used against the fixed dimm.ko)

Plus dimm-fixed.ko = stock dimm.c + fix.diff.

Run (baseline — expect panic)

# guest, root:
kldload dimm                       # module-mode dimm (shipped dimm.ko)
kldload /root/df5011/drainpoc.ko   # creates dimm_softc, holds ref=1
sysctl hw.dimminfo                 # hw.dimminfo.dimm0.* present
kldunload dimm                     # BUG: rc=0 — drains+free live softc
sysctl hw.dimminfo                 # "unknown oid" (object destroyed)
kldunload drainpoc                 # dimm_destroy on freed object +
                                   # call into unmapped dimm.ko text
                                   # -> Fatal trap 12, system down

Expected result (all observed, see run.log / panic.txt)

1. kldunload dimm returns 0 although a live creator holds the only reference (should be refused — the module owns no references of its own).
2. hw.dimminfo.dimm0.* disappears: the drain loop ran dimm_destroy() on the user's softc (kfree at dimm.c:195, sysctl teardown at :193-194).
3. The victim's next KPI call faults: Fatal trap 12: page fault while in kernel mode, fault virtual address = 0xffffffff826004a0 (= dimm.ko text base 0xffffffff82600000 + 0x4a0), supervisor read instruction, page not present → DDB, system dead.

Fix validation (run.3.log)

With fix.diff applied to dimm.ko: * kldunload dimm-fixed with pocfix holding a live ref → "Device busy" (rc=1), console: dimm0 is still referenced (ref 1); cannot unload. * hw.dimminfo.dimm0.* still present; victim can destroy its ref properly. * After the victim's clean destroy, kldunload dimm-fixed → rc=0. * No panic, no drain.

VERDICT — DF-5011: dimm_mod_unload() drains foreign dimm_softc references (UAF → panic)

• file : sys/dev/misc/dimm/dimm.c
• root cause : dimm.c:305-321 (dimm_mod_unload) — the MOD_UNLOAD loop calls dimm_destroy(TAILQ_FIRST(...)) until the list is empty; every call decrements a reference OWNED BY A KPI USER (dimm_destroy: dimm.c:183-188) and frees the softc at dimm.c:190-195 when it reaches zero. The framework itself holds no references, so "list non-empty at unload" ALWAYS means a driver (ecc_e3/ecc_e5/memtemp_core/memtemp_e5 or any out-of-tree user) still holds live struct dimm_softc * pointers.
• reproduced : YES — baseline panic on the QEMU guest (run.log, panic.txt)
• impact : kernel panic (root-triggered; module-unload path)
• fix validated : YES — fix.diff (EBUSY veto), behavior contrast in run.3.log

Attack surface / threat model

dimm.c has zero unprivileged entry points (no /dev node, no ioctls, no packet path; sysctl writes are gated by SYSCAP_NOSYSCTL_WR — kern_sysctl.c:1446). The defect is on the module-administration path: it takes an privileged user (root) to run kldunload dimm. The reason it is still a real kernel bug rather than "root did it to itself": the dimm KPI contract is dimm_create() returns a refcounted handle, dimm_destroy() releases ONE reference, and the owner expects the object to live until its OWN destroy. dimm.c unilaterally violates that contract from a third party's kldunload. In-tree victim: ecc_e3.c (sys/dev/misc/ecc/ecc_e3.c:387 uses dimm_create; :156-157 declares MODULE_DEPEND only on pci and coremctl — NOT on dimm), so on E3 hardware with module-mode dimm, kldunload dimm while ecc_e3 is attached+live frees ecc_e3's softcs; the next ECC interrupt calls dimm_sensor_ecc_add() on freed memory / unmapped module text → panic or silent heap corruption. (ecc_e5/memtemp_* do declare MODULE_DEPEND and are protected by the linker's refs — verified live in run.2.log: "Device busy".)

Why the linker does not save dep-less users

kern_linker.c:477-518 linker_file_unload(): with no MODULE_DEPEND there is no reference on dimm.ko, so kldunload dimm runs module_unload → dimm_mod_event(MOD_UNLOAD) → the drain. DragonFly's kldunload has no -f flag; the missing dependency is the enabler.

What was run (all as root on the guest)

Kernel: custom X86_64_GENERIC without device dimm/device ecc/device memtemp (nativekernel build; necessary because the stock generic kernel compiles dimm in, where MOD_UNLOAD never runs). Stock shipped /boot/kernel/dimm.ko was the module under test (rebuilt by installkernel from unmodified source).

BASELINE (run.log): kldload dimm → ok kldload drainpoc.ko (no MODULE_DEPEND) → "sc=0xfffff800899b0800 ref=1" sysctl hw.dimminfo → dimm0 present kldunload dimm → rc=0 <-- CONTRACT VIOLATION sysctl hw.dimminfo → "unknown oid" (softc kfreed) kldunload drainpoc → MOD_UNLOAD calls dimm_destroy: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffffffff826004a0 (dimm.ko text + 0x4a0) instruction pointer = 0x8:0xffffffff826004a0 fault code = supervisor read instruction, page not present → all CPUs stopped, DDB prompt, system down. (Serial console proves ordering: the drain+free happened silently during kldunload dimm; the fault is the victim's call, exactly what an ecc_e3 ECC interrupt would do.)

CONTROL (run.2.log) — same PoC WITH MODULE_DEPEND(dimm,1,1,1): kldload deppoc.ko → dimm.ko AUTO-loaded as dependency kldunload dimm (deppoc live) → "can't unload file: Device busy" kldunload deppoc → rc=0, clean destroy, dimm released → isolates the defect to dimm.c's own unload path + dep-less users.

FIX VALIDATION (run.3.log) — fix.diff applied to dimm.ko, dep-less pocfix: kldunload dimm-fixed (pocfix live) → "Device busy", console: "dimm0 is still referenced (ref 1); cannot unload" hw.dimminfo.dimm0.node still readable; pocfix's own destroy works (dimm still mapped); final kldunload dimm-fixed → rc=0 with empty list. No drain, no free, no panic.

Exploitability ceiling

The primitive is a kernel use-after-free/write (refcount dec + TAILQ_REMOVE + kfree of an object still in use), but the trigger is privileged (kldunload). No unprivileged path exists. Realistic worst case: root-caused kernel panic or heap corruption on ECC-capable servers during module administration. Severity Low (per rubric: "requires already-privileged user").

Classification

status : reproduced reproduced : 1 impact : panic confidence : certain fix_status : fixed (baseline drain/panic gone with patch; clean lifecycle kept)

Kernel references

sys/dev/misc/dimm/dimm.c:305-321 buggy unload loop (drain) sys/dev/misc/dimm/dimm.c:178-199 dimm_destroy decrements user's ref, frees at :195 sys/dev/misc/ecc/ecc_e3.c:156-157 missing MODULE_DEPEND(ecc_e3, dimm) (enabler) sys/kern/kern_linker.c:477-518 unload refs come only from MODULE_DEPEND sys/config/X86_64_GENERIC:189 device dimm (why stock guest is inert here)

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.