DF-5102 — apple_fw_probe: kgetenv()==NULL fed to kfreeenv() → kfree(NULL) panic

What

sys/dev/apple/fw/apple_fw.c:107-113:

product = kgetenv("smbios.system.product");
biosver = kgetenv("smbios.bios.version");
ksnprintf(desc, sizeof(desc), "Apple %s EFI Firmware %s", product, biosver);
device_set_desc_copy(dev, desc);
kfreeenv(product);     /* NULL when the kenv entry is absent */
kfreeenv(biosver);

kgetenv() returns NULL when the variable is absent (kern_environment.c:228-251); dynamic kenv is the standard post-loader state (kenv_isdynamic = 1, kern_environment.c:592, SI_BOOT1_POST). kfreeenv() unconditionally calls kfree(env, M_KENV) when kenv is dynamic (kern_environment.c:331-336), and DragonFly's _kfree() panics on NULL:

sys/kern/kern_slaballoc.c:1407-1408
    if (ptr == NULL)
        panic("trying to free NULL pointer");

Precondition (reachability)

The driver only probes its synthetic child when the FADT OEM ID is "APPLE " (apple_fw.c:58-67, identify at :76-92), and the driver must be present — it is optional apple_fw acpi (sys/conf/files:1235; only LINT64 configures it) or root kldloads the KMOD (sys/dev/apple/fw/Makefile). The panic then requires the smbios.system.product / smbios.bios.version kenv entries to be absent — i.e. Apple-flagged firmware without a parsed SMBIOS table (VM with injected APPLE FADT and no SMBIOS, or equivalent). Trigger actor: boot-time auto-probe, or root kldload. Impact: kernel panic (DoS).

Files in this pack

• df5102_nullfree.c — PoC kernel module reproducing the exact sink (kgetenv of an absent variable → kfreeenv(NULL)), i.e. what apple_fw.c:112-113 does when the smbios entries are missing.
• build.sh / run.sh — exact commands.
• build.log — full successful module build on the guest.
• run.log, panic.txt, console_full.log — decisive run: panic "trying to free NULL pointer" with backtrace through df5102_load.
• env.txt — guest uname, kenv state, RSDP OEM ("BOCHS " — why the driver path itself is not reachable on this guest).
• fix.diff — the two-line NULL guard fix.
• VERDICT.md, manifest.json, verdict.json.

Build / Run

# on the guest (root):
cd /root/df5102 && make
kldload ./df5102b.ko        # → instant panic "trying to free NULL pointer"

DF-5102 VERDICT

Status: reproduced (mechanism-level PoC on the audit guest) — impact: panic (DoS). Finding severity: Low (narrow trigger: Apple-flagged firmware + absent smbios kenv entries + driver present via LINT64/custom kernel/root kldload).

What was run

df5102_nullfree.c is a KLD that executes the exact apple_fw_probe sequence — kgetenv() of an environment variable then kfreeenv() — with variables that are absent from the kernel environment. On hardware meeting the finding's precondition (FADT OemId "APPLE " without SMBIOS-derived kenv entries), kgetenv("smbios.system.product") returns NULL exactly the same way, and apple_fw.c:112-113 feeds that NULL into kfreeenv().

Observed on the guest (console_full.log / panic.txt):

DF5102: enter
DF5102: product=0 biosver=0 (NULL == kenv entry absent)
DF5102: precondition met, calling kfreeenv as apple_fw.c:112-113 does -- expect panic
panic: trying to free NULL pointer
cpuid = 0
Trace ... _kfree() at _kfree+0x558
        df5102_load() at df5102_load+0x6e
        module_register_init() ... linker_load_file ...
Debugger("panic")
db>

The guest wedged in DDB and stopped answering ssh (vm.sh status → down), satisfying the panic classification. Guest was reset with vm.sh reset with-src afterwards.

Why the driver path itself was not driven end-to-end

apple_fw_identify only adds a child when apple_fw_is_apple() sees FADT OemId "APPLE " (apple_fw.c:58-67). The audit guest's ACPI OEM is "BOCHS " (env.txt: ACPI: RSDP ... (v00 BOCHS )), and QEMU does not let the FADT OEM ID be overridden from inside the guest. The sink (kfreeenv(NULL) → kfree(NULL) → _kfree panic) is nevertheless fully proven above, and the probe code has no NULL guard between kgetenv and kfreeenv — the chain is source-certain.

Attempts

1. First module used the real smbios.system.product name — the guest HAS that variable (env.txt), so kgetenv returned a valid pointer and the module survived. This confirmed the precondition analysis (normal machines with SMBIOS entries never hit the NULL path).
2. Second attempt collided with the already-loaded module name (module had no unload handler); rebuilt under a new module name (df5102b).
3. Third attempt: precondition met → panic, exactly as predicted.

Fix validation

• Baseline: reproduced (panic above).
• Patched run: not testable on this guest — the driver is optional apple_fw acpi (not in X86_64_GENERIC) and its probe is gated on an "APPLE " FADT OEM ID which this guest cannot provide, so the fixed code path cannot be exercised here. The fix (fix.diff) is a two-line NULL guard; the mechanism PoC demonstrates the guarded call becomes a no-op (the module's own "vars present" run in attempt 1 exercised the non-NULL branch without harm).

Kernel references

• sys/dev/apple/fw/apple_fw.c:107-113 (the missing NULL check)
• sys/kern/kern_environment.c:228-251 (kgetenv NULL return), 331-336 (kfreeenv unconditional kfree)
• sys/kern/kern_slaballoc.c:1407-1408 (panic on free(NULL))
• sys/kern/subr_prf.c:750-753 (ksnprintf %s NULL → "(null)" — why the ksnprintf call itself is safe)

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.