DF-2772 — findbase()==0 → panic("lost base for relatab") on REL/RELA whose sh_info doesn't name a loaded section

Build (host)

python3 gen_module.py df2772.ko panic-rela

Run (guest, root — kldload is SYSCAP_NOKLD-gated)

scp -F dfbsd-qemu/config df2772.ko dfbsd:/tmp/
dfbsd-qemu/vm.sh run_root 'kldload /tmp/df2772.ko'

Expected — stock kernel (baseline, reproduced twice)

Serial console (panic.txt):

panic: lost base for relatab
link_elf_obj_reloc_local() at link_elf_obj_reloc_local+0x28f
link_elf_obj_load_file() at link_elf_obj_load_file+0xb6f
linker_load_file.part.3() ... sys_kldload() ...
Debugger("panic")

The module's single .rela section carries sh_info = 0 (the SHT_NULL section). The scan stores it verbatim (sec = sh_info, link_elf_obj.c:355/:775), and since section 0 never becomes a progtab entry, findbase() returns 0 and link_elf_obj_reloc_local (called during load, :818→:1243-1245 / during boot for preloads :368) executes panic("lost base for relatab") instead of rejecting the file. Same shape at :975-977/:1002-1004 in relocate_file.

Expected — patched kernel (fix.diff applied, kernel #1 Sep 1 2026)

kldload: an error occurred while loading module /tmp/df2772.ko ...
RC=1
dmesg: linker_load_file: Unsupported file type

Module rejected at scan time by elf_obj_reloc_target_ok(), no panic, guest up.

Threat model

Root-supplied-input class (SYSCAP_NOKLD), like DF-0040/0041/0042. The same panic is also reachable from the preload path (boot-time module metadata), so a corrupted/substituted preloaded module bricks the boot.

DF-2772 — VERDICT

REPRODUCED (panic / DoS, root-gated).

Root cause (sys/kern/link_elf_obj.c)

REL/RELA sections are recorded with their raw sh_info as the target-section number, with no validation that the target is (or will be) a loaded PROGBITS/NOBITS section:

772:        case SHT_REL:
773:            ef->reltab[rl].rel = kmalloc(shdr[i].sh_size, ...);
774:            ef->reltab[rl].nrel = shdr[i].sh_size / sizeof(Elf_Rel);
775:            ef->reltab[rl].sec = shdr[i].sh_info;      /* raw, unchecked */
...
791:            ef->relatab[ra].sec = shdr[i].sh_info;      /* raw, unchecked */

Later, findbase() (:940-953) returns 0 unless some progtab entry carries that exact section index, and both relocation drivers turn 0 into a panic:

975:        base = findbase(ef, ef->reltab[i].sec);
976:        if (base == 0)
977:            panic("lost base for reltab");
...
1002:       base = findbase(ef, ef->relatab[i].sec);
1003:       if (base == 0)
1004:           panic("lost base for relatab");

and identically in link_elf_obj_reloc_local (:1243-1245, :1265-1267), which runs from link_elf_obj_load_file:818 (kldload path) and link_elf_obj_preload_file:368 (boot path). Any crafted module with a nonempty REL/RELA section whose sh_info names the NULL section (0), a STRTAB/SYMTAB section, an index ≥ e_shnum, or a size-0 PROGBITS section (size-0 sections are never entered into progtab, :518-519/:697-698) panics the kernel instead of being rejected with an error.

Reproduction (baseline, stock kernel)

Guest: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 … X86_64_GENERIC, securelevel -1. gen_module.py df2772.ko panic-rela emits a 514-byte ET_REL object: .text, .symtab (1 null sym), .strtab, .shstrtab, and one .rela (24 bytes, sh_info=0). kldload /tmp/df2772.ko → ssh hangs; serial console (panic.txt):

panic: lost base for relatab
link_elf_obj_reloc_local() at link_elf_obj_reloc_local+0x28f
link_elf_obj_load_file() at link_elf_obj_load_file+0xb6f
linker_load_file.part.3() at linker_load_file.part.3+0x92
linker_load_module() at linker_load_module+0x116
sys_kldload() at sys_kldload+0xc6
Debugger("panic")

Reproduced twice on fresh vm.sh reset with-src boots (first run, then a re-run on a fresh reset to capture the clean excerpt).

Impact ceiling

Deterministic kernel panic from a crafted module — a robustness/DoS defect, not a corruption primitive (nothing is written; the panic is the whole effect). kldload is root-only (caps_priv_check_self(SYSCAP_NOKLD), kern_linker.c:792; blocked at securelevel>0), so unprivileged reach is nil; the interesting real-world framing is a corrupted or substituted module (incl. a preloaded one, which converts this into a boot-time brick). Low severity, consistent with DF-0040/0041/0042 calibration.

Fix validation

fix.diff (same combined patch as DF-2771/DF-2773): new elf_obj_reloc_target_ok() validates sh_info < e_shnum + target type PROGBITS/NOBITS (+ nonempty for the file case) in both scan loops (preload :234-239, file :530-535) before the section is counted, and the four panic("lost base …") sites become return (ENOEXEC) with the error propagated (link_elf_obj_reloc_local becomes int-returning; callers :368 and :818 check it). Rebuilt kernel (make -j6 nativekernel KERNCONF=X86_64_GENERIC, build.log, -Werror clean), installed as #1: Tue Sep 1 01:04:57 UTC 2026, rebooted. Same PoC:

kldload: an error occurred while loading module /tmp/df2772.ko. Please check dmesg(8)
dmesg: linker_load_file: Unsupported file type
RC=1, guest stays up (ALL-SURVIVED), 0 panics

Baseline panic gone → fix_status=fixed.

Note on scope

The scan-time rejection intentionally runs before the nprogtab/nsym checks; the goto-out it takes was made safe by the DF-2773 unload guard in the same patch (previously a scan-time rejection with nrelatab>0 and relatab==NULL would itself have NULL-derefed in unload).