DF-5364 — Unchecked kmalloc(M_NOWAIT) in FUNCID/CONFIG tuple handlers: NULL-page write on allocation failure

File: sys/bus/pccard/pccard_cis.c (pass 2, GLM 5.3). Full narrative: VERDICT.md.

Reproduce (deterministic userland model of the kernel parse/consume chains)

./build.sh                 # cc -O2 -Wall -o poc_pccard_cis2 poc_pccard_cis2.c
./run.sh                   # ./poc_pccard_cis2 kmallocfail

Expected decisive output: the RESULT: DF-5364 ... line (see run.log; exit 0). Built and executed on the DragonFly guest toolchain (DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT), cc 8.3. The QEMU guest has no PCMCIA bridge, so the kernel path itself is not enterable; the model mirrors pccard_cis.c:100-444 (walk), :612-1260 (handlers), decode_funce :1262-1294 and the pccard.c:429-474 consumer loops statement-by- statement. Run ./poc_pccard_cis2 all for every scenario incl. negatives.

What it proves: Injected alloc failure -> (int)(NULL+0) write at :792/:839 (offsetof(number)==0). Recommended fix: NULL-check both allocations (error++ + break) and guard CFTABLE top-of-case (also hardens DF-2319) (fix.diff).

DF-5364 — Unchecked kmalloc(M_NOWAIT) in FUNCID/CONFIG handlers: NULL-page write

Verdict in one line

Statically certain (model-demonstrated address computation): both kmalloc(sizeof(*state->pf), M_DEVBUF, M_NOWAIT | M_ZERO) calls in the tuple parser are immediately dereferenced with no NULL check — on allocation failure the very next statement writes through NULL.

Root cause (path:line)

CISTPL_FUNCID handler:

if ((state->pf == NULL) || (state->gotmfc == 2)) {
        state->pf = kmalloc(sizeof(*state->pf), M_DEVBUF,
            M_NOWAIT | M_ZERO);                    /* :790-791  unchecked */
        state->pf->number = state->count++;         /* :792  NULL+0 write */
        ...

CISTPL_CONFIG handler:

if (state->pf == NULL) {
        state->pf = kmalloc(sizeof(*state->pf),
            M_DEVBUF, M_NOWAIT | M_ZERO);           /* :837-838  unchecked */
        state->pf->number = state->count++;         /* :839  NULL+0 write */

The CFTABLE handler in the same function does it correctly (if (cfe == NULL) { DPRINTF(...); goto abort_cfe; } at :910-913), which makes the omission plain.

offsetof(struct pccard_function, number) == 0, so the write is to virtual address 0 — an immediate kernel page fault / panic on amd64 and i386.

Trigger / preconditions

pccard_parse_cis_tuple runs at every card insertion (pccard.c:195). The allocation is small (~150 B), so failure requires kernel memory pressure (kmalloc M_NOWAIT failing) — e.g. an already-memory-starved system at card insert, or an attacker combining it with the DF-5362+DF-5361 unbounded leak-loop to manufacture the exhaustion, then re-inserting a card whose CIS leads with FUNCID or CONFIG. Low severity (DoS on top of memory exhaustion), certain as a code defect.

Model evidence (run.log, scenario kmallocfail)

=== S6 kmallocfail ===
RESULT: DF-5364 FUNCID kmalloc(M_NOWAIT) returned NULL; next kernel
  statement writes *(int*)(NULL+0) = 0  -> NULL-page write, panic

(The model injects a single allocation failure at the FUNCID pf alloc and reports the address the kernel write would target; offsetof(number)=0.)

Fix

Check for NULL and bail out of the tuple (fix.diff, also adds the top-of-case guard in CFTABLE that hardens the DF-2319 default_cfe/pf NULLs so the new break-outs cannot re-expose them).

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.