# DF-4690 -- verdict narrative

## Claim
decode_tuple_bar keeps the attacker-controlled 32-bit CIS BAR size when the PCI probe
fails (`pci_bar == 0 || pci_bar == 0xffffffff`, cardbus_cis.c:362) and assigns it to the
INT parameter `len` (:308) -> values >= 2^31 truncate to negative; independently, a BAR
probing 0x80000000 gives `1 << (ffs(0x80000000)-1)` = `1 << 31` (:368) -- signed overflow
UB that manifests as INT_MIN. Both reach resource_list_add(:377) as a NEGATIVE count for
the child's resource list entry.

## Reproduced?
YES, decoder-level (verbatim extraction, run on the DragonFly guest; the accepted DF-1811
used the same source-only standard because no CardBus bridge exists on the guest).

* mode 1: cis size field 0xFFFFFFF0, probe 0xffffffff -> count = -16 (0xfffffff0)
* mode 2: probe 0x80000000 -> ffs==32 -> 1<<31 UB -> count = -2147483648 (0x80000000)
* mode 3 (contrast = known DF-1811): masked probe 0 -> ffs(0)-1 UB -> INT_MIN

A negative `count` in a resource-list entry is nonsense downstream (rman allocation for
the child driver); the realistic ceiling is the card's own driver failing to attach /
resource misbehavior -- hardware-gated, no local or remote trigger. Severity Low.

## Fix validation (fix_validate.sh, fix.diff = fix4690.diff)
Baseline: negative counts reach resource_list_add (above). Patched (reject pci_bar==0
after mask [the DF-1811 half] and len<=0 before resource_list_add): all three cases
return EINVAL and the captured count keeps its sentinel 0x42424242 -- resource_list_add
is never reached. FIXED at decoder level.

## 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.