DF-1041 PoC — CISTPL_CFTABLE_ENTRY power/misc unbounded read loops

Verdict

REPRODUCED (harness-level — runtime unreachable on guest without PCMCIA HW). Fix VALIDATED on a built-and-booted single-fix kernel.

See VERDICT.md for the full narrative. See manifest.json for the artifact catalog. The decisive log is run.log; fix_build.log is the full 35553-line single-fix kernel build.

Why a harness (not a runtime panic)

The QEMU/KVM audit guest has no PCMCIA/CardBus bridge — devinfo shows no pccard/cbb device, /dev/pccard* and /dev/cardbus* do not exist, and there is no syscall/ioctl/devfs path that feeds attacker bytes into pccard_parse_cis_tuple. The bug is latent, triggerable only by physical PCMCIA card insertion (the threat model in the finding markdown).

harness.c is a verbatim, line-cited replication of the CFTABLE_ENTRY parser (pccard_cis.c:871-1253) that demonstrates the unbounded idx growth on the supplied CIS image without needing real PCMCIA hardware. This follows the precedent set by sibling finding DF-1040 (same parser).

Trigger

CIS attribute-memory image containing a malformed CISTPL_CFTABLE_ENTRY:

(cis_image.bin is the 64 KiB version of this — every even byte after 0x0C is 0xFF. The kernel's PCCARD_CIS_SIZE is 4096, so on real HW the panic would occur much earlier, at byte_off >= 4096, i.e. idx >= 2046.)

Build & run

./build.sh       # cc -O2 -Wall -o harness harness.c
./run.sh         # ./harness cis_image.bin

Expected:

=== UNPATCHED (master pccard_cis.c) ===
final idx reached        = 50001 bytes        (cap; first OOB at idx=32766)
=== PATCHED (fix.diff: idx>=length -> abort_cfe) ===
final idx reached        = 8 bytes            (capped at length=8)
SUMMARY: unpatched idx=50001 (>49993 past length) vs patched idx=8 (==length).

harness_valid (run separately) confirms the fix doesn't break legitimate input — both branches reach the same idx on a well-formed tuple.

On real hardware

A malicious PC Card / CardBus card flashed with this CIS, when inserted into a DragonFlyBSD system with the default kernel, drives the parser's idx past the 4096-byte bus-space CIS window. The expected kernel panic:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x<offset past bridge window>
pccard_parse_cis_tuple(...) at pccard_cis.c:996   (or :1244)
pccard_scan_cis(...) at pccard_cis.c:349

Kernel references

• sys/bus/pccard/pccard_cis.c:984-1007 — power parameter loop (no length guard)
• sys/bus/pccard/pccard_cis.c:995-1003 — do-while continuing on card byte's bit 7
• sys/bus/pccard/pccard_cis.c:1243-1246 — misc-extension while loop (no length guard)
• sys/bus/pccard/pccard_cis.c:1024, 1102, 1134, 1225 — existing length checks
• sys/bus/pccard/pccard_cis.c:62 — PCCARD_CIS_SIZE 4096
• sys/bus/pccard/pccardvar.h:255-259 — pccard_tuple_read_1 (no length check)

DF-1041 — VERDICT

Verdict

REPRODUCED (at the harness level — runtime unreachable on this guest). The bug is real and the fix is validated on a built-and-booted single-fix kernel.

Severity: Low. Local/physical DoS via a malicious PCMCIA card. No privilege-escalation surface — the corrupted reads are byte comparisons that the parser immediately discards (/* skip over power, don't save */, pccard_cis.c:985; cfe->maxtwins = reg & ... then the rest is dropped).

Why runtime-inconclusive on this guest (but code-certain)

The guest has no PCMCIA/CardBus bridge hardware:

$ ssh dfbsd-maxx 'devinfo 2>/dev/null | grep -iE "pccard|pcmcia|cardbus|cbb"'
(empty)
$ ls /dev/pccard* /dev/cardbus*
ls: No such file or directory

The kernel compiles in pccard and cbb (they show in kldstat -v), but with no bridge device the pccard_scan_cis code path is never entered. There is no syscall, devfs node, or ioctls that feeds attacker-controlled CIS bytes into pccard_parse_cis_tuple. This is a latent bug triggerable only by physical PCMCIA card insertion (the threat model in the finding markdown). Per the procedure (and the precedent set by DF-1040, the sibling finding in the same parser), the bug is confirmed via source-level trace + userspace harness replicating the parser logic verbatim.

Mechanism (source trace)

pccard_parse_cis_tuple (sys/bus/pccard/pccard_cis.c) handles CISTPL_CFTABLE_ENTRY (0x1B) starting at line 871. Inside, two loops advance the parse index idx without ever comparing it against tuple->length:

Bug locus 1 — power do-while (pccard_cis.c:995-1003)

if (power) {                                            /* :984 */
    for (i = 0; i < power; i++) {                       /* :987 */
        reg = pccard_tuple_read_1(tuple, idx); idx++;   /* :988 */
        for (j = 0; j < 7; j++) {                       /* :991 */
            if ((reg >> j) & 0x01) {                    /* :993 */
                do {
                    reg2 = pccard_tuple_read_1(tuple, idx);   /* :996 */
                    idx++;                                     /* :997 */
                } while (reg2 & 0x80);                  /* :1003 */
            }
        }
    }
}

Termination is solely on the card-supplied byte's bit 7. A malicious card that keeps bit 7 set forces idx to grow indefinitely. There is no entry guard (if (tuple->length <= idx) goto abort_cfe;) before this block, and no in-loop guard. Compare the iospace/irq/memspace/misc-entry guards at pccard_cis.c:1024, 1102, 1134, 1225.

Bug locus 2 — misc-extension while loop (pccard_cis.c:1243-1246)

if (misc) {
    if (tuple->length <= idx) goto abort_cfe;           /* :1225 entry guard */
    reg = pccard_tuple_read_1(tuple, idx); idx++;       /* :1230 */
    ...
    while (reg & PCCARD_TPCE_MI_EXT) {                  /* :1243 */
        reg = pccard_tuple_read_1(tuple, idx);          /* :1244 — NO guard */
        idx++;                                          /* :1245 */
    }
}

The misc section has an entry guard at line 1225 but the continuation while loop reads again with no guard. Same continuation-bit-trust bug.

Sink

pccard_tuple_read_1(tuple, idx) (sys/bus/pccard/pccardvar.h:258-259):

#define pccard_tuple_read_1(tuple, idx1) \
    (pccard_cis_read_1((tuple), ((tuple)->ptr+(2+(idx1)))))

#define pccard_cis_read_1(tuple, idx0) \
    (bus_space_read_1((tuple)->memt, (tuple)->memh, (tuple)->mult*(idx0)))

No length validation. When mult*(ptr+2+idx) exceeds the 4096-byte PCCARD_CIS_SIZE bus-space mapping (pccard_cis.c:62, 131), bus_space_read_1 page-faults → kernel panic.

Harness demonstration

harness.c is a verbatim, line-cited replication of the CFTABLE_ENTRY parser. Fed cis_image.bin (declared length 8, all-0xFF continuation bytes), the harness reports:

=== UNPATCHED (master pccard_cis.c) ===
declared tuple->length   = 8 bytes
pccard_tuple_read_1 calls= 50001 (harness cap=50000)
final idx reached        = 50001 bytes
overshoot past length    = 49993 bytes (idx grew 6250x past declared length)
kernel byte offset       = mult*(ptr+2+idx) = 2*(0+2+50001) = 100006
faulted past img_len?    = YES
  -> first OOB read at idx=32766, byte_off=65536 (>= img_len=65536)

In the actual kernel with PCCARD_CIS_SIZE = 4096 (pccard_cis.c:62), the page-fault panic occurs at byte_off >= 4096, i.e. idx >= 2046. The 65536-byte image in the harness makes the demonstration robust; the bug manifests identically regardless of image size — what matters is that idx runs past the declared tuple body with no length-based termination.

=== PATCHED (fix.diff: idx>=length -> abort_cfe) ===
final idx reached        = 8 bytes (capped at length=8)
pccard_tuple_read_1 calls= 8
overshoot past length    = 0 bytes
faulted?                 = no

harness_valid.c further proves the fix is benign on legitimate input: a well-formed CFTABLE_ENTRY tuple parses to the same idx (5 reads) under both unpatched and patched logic.

Exploit chain

none — read-only OOB. There is no privilege boundary to cross. The read bytes feed only reg2 & 0x80 (continuation test) and cfe->maxtwins = reg & 0x03 (a 2-bit field), and the parser doesn't exfiltrate the bytes anywhere observable to userspace. Realistic impact ceiling: kernel panic on physical card insertion.

Recommended fix (validated)

fix.diff — adds if (idx >= tuple->length) goto abort_cfe; at the top of the power do-while body (pccard_cis.c:995) and at the top of the misc while-loop body (pccard_cis.c:1243), mirroring the existing tuple->length <= idx checks already present at lines 1024, 1102, 1134, 1225. Reuses the existing abort_cfe label (pccard_cis.c:1251).

Matches finding proposal — the diff is byte-for-byte the one in the finding markdown's ## Recommended fix section.

Phase 8 — fix validation

• Baseline (#0, unpatched): harness UNPATCHED branch reproduces the bug (idx→50001, first OOB read at idx=32766). Booted 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026, kernel sha256 5dc83dac19ad09effd6241c33e0c0669d41b6497ee92d87d3a2e45f287bc22ad.
• Apply fix: patch -p1 --forward < /root/fix.diff → both hunks applied cleanly.
• Build: make -j6 nativekernel KERNCONF=X86_64_GENERIC → rc=0, 35553-line log, pccard_cis.c recompiled with -Werror and no errors.
• Install + reboot: copied kernel.stripped + kernel.debug, rebooted. New kernel: 6.5-DEVELOPMENT #1: Tue Jul 14 14:55:19 UTC 2026, sha256 e37bbca3558de6abb66906b850f2d2c0791e7e7bea732629fed1f5eb71d8ac27.
• Confirm patched source in running kernel: sed of /usr/src/sys/bus/pccard/pccard_cis.c shows the bounds checks in place at lines 995-996 and 1244-1245.
• Confirm code path closed: harness PATCHED branch (the fix.diff logic) aborts at idx=8 (== declared length), no OOB read.

Since the parser is unreachable at runtime on this guest, the runtime behavior of the booted single-fix kernel cannot differ from the unpatched one (neither triggers anything without PCMCIA HW). The validation is at the compile+source+harness level — the fix closes the code path the bug traces through.

PoC changes

• Added harness.c — userspace verbatim replication of the CFTABLE_ENTRY parser, demonstrating the unbounded idx growth on the supplied CIS image.
• Added harness_valid.c — well-formed-tuple sanity test proving the fix is benign on legitimate input.
• Added build.sh / run.sh — exact build and run commands.
• Added fix.diff — the recommended fix, matches the finding proposal.
• Removed the placeholder Python CIS-image generator snippet from the README (the binary cis_image.bin ships with the evidence pack).

Kernel references

• sys/bus/pccard/pccard_cis.c:984-1007 — power loop, missing length guard
• sys/bus/pccard/pccard_cis.c:995-1003 — power do-while, the bug locus 1
• sys/bus/pccard/pccard_cis.c:1243-1246 — misc while loop, bug locus 2
• sys/bus/pccard/pccard_cis.c:1024, 1102, 1134, 1225 — existing length <= idx guards that the power/misc loops should mirror
• sys/bus/pccard/pccard_cis.c:62 — PCCARD_CIS_SIZE 4096 (the bus mapping size)
• sys/bus/pccard/pccard_cis.c:871-1253 — the CISTPL_CFTABLE_ENTRY handler
• sys/bus/pccard/pccardvar.h:255-259 — pccard_cis_read_1 / pccard_tuple_read_1 (no length check)