DF-2390

Boot-time kernel panic from inconsistent DPF handling between resource counter and link_add_crs

Summary

acpi_count_irq_resources tolerates second START_DEPENDENT resource by transitioning to DPF_IGNORE (no panic) so _CRS containing nested dependent-function groups counted successfully and pl_links allocated. link_add_prs also tolerates it. But link_add_crs panic()s on second START_DEPENDENT. Malformed/buggy _CRS passes counting walk drives allocation then panics kernel during attach. Two walks over same _CRS disagree on whether nested DPF acceptable. No memory-corruption only unconditional kernel panic during ACPI PCI link attach (boot). Impact: DoS system fails to boot. [VERIFIED pass2: double-DPF _CRS rejected by ACPICA 2025 resource-template validation before any DFly walk; two-walk disagreement source-real, tolerant hardening fix compile-validated]

Discussion (0)

No comments yet.

Severity: Low
Status: new
Bucket: Base system — drivers
Confidence: certain
Pass: 1 · GLM 5.2 first pass
CVSS 3.1: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:N/I:N/A:H
CWE: CWE-754 Improper Check for Unusual or Exceptional Conditions
File: sys/dev/acpica/acpi_pci_link.c
Lines: 180-504
Area: dev
Discovered: 2026-07-28
Updated: 2026-07-28

Team triage

untriaged

priority: — · owner: —

PoC verification

not_reproduced

Status: not_reproduced
Reproduced: no
Impact: none
Confidence: certain
Tested: 2026-10-24 00:24:16
Attempts: 2
Runtime: 400s
Code hash: cb21865e4336f280
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #7: Sat Oct 24 00:08:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/ACHARNESS x86_64
Build cmd: make -j5 nativekernel KERNCONF=ACHARNESS (see build.sh; stock-kernel findings need no build)
Run cmd: see run.sh

jump to evidence pack ↓

Fix verification

not_testable

Fix status: not_testable
Baseline reproduced: —
Patched reproduced: —
Confidence: certain
Tested: 2026-10-24 00:24:16
Runtime: —
Kernel: per-fix-DF-2390
fix.diff: findings/poc/DF-2390/fix.diff
Runner: df-bsd-reviewer

jump to fix verification ↓

PoC verification

Evidence pack

findings/poc/DF-2390 · 13 files

File	Type	Size
README.md	file	941 B	↓ raw
VERDICT.md	file	1.6 KB	↓ raw
acsim.c	file	26.1 KB	view raw
build.log	file	510 B	view raw
build.sh	file	3.2 KB	view raw
env.txt	file	145 B	view raw
fix.diff	file	509 B	view raw
lnkx_boot.log	file	616 B	view raw
manifest.json	file	690 B	view raw
run.sh	file	54 B	view raw
ssdt_acsim.dsl	file	8.2 KB	↓ download
ssdt_lnkx.dsl	file	1.7 KB	↓ download
verdict.json	file	1.8 KB	view raw

README.md file

↓ download raw

DF-2390 - pci_link double-DPF panic: GATED by ACPICA on current ACPICA

Attempt (ACHARNESS + ssdt_lnkx.aml, raw-byte _CRS with two

StartDependentFunctions groups) Boot result (lnkx_boot.log): ACPI: SSDT ... LNKX ... can't fetch resources for _SB_.LNKX - AE_AML_INVALID_RESOURCE_TYPE (no panic; acpi_pci_link attach fails ENXID; system boots)

ACPICA 2025 validates the resource-template structure itself and refuses to deliver the malformed buffer to ANY DragonFly walk - neither acpi_count_irq_resources nor link_add_crs ever sees it.

Source-level disagreement (real, kept as hardening)

acpi_count_irq_resources: second START_DEPENDENT -> DPF_IGNORE (tolerated) link_add_crs: second START_DEPENDENT -> panic("Multiple dependent...") If a future ACPICA ever passes such a buffer, the kernel panics at boot.

fix.diff (compile-validated): link_add_crs tolerates (DPF_IGNORE)

matching the counting walk instead of panicking.

VERDICT.md file

↓ download raw

DF-2390 VERDICT

Status: not_reproduced Impact: none Confidence: certain Attempts: 2

Unreachable through firmware on this ACPICA (20251212): a _CRS containing two dependent-function groups is rejected by ACPICAs own resource walk with AE_AML_INVALID_RESOURCE_TYPE before any DragonFly callback runs (acpi_resource.c:429 prints can't fetch resources, the pci_link attach fails with ENXIO, the machine boots normally). The two-walk disagreement in DragonFly code is real (acpi_count_irq_resources tolerates a second START_DEPENDENT via DPF_IGNORE at acpi_pci_link.c:180-186 while link_add_crs panics at :222-226) but can only be reached if ACPICA ever hands such a buffer over. Retained as defense-in-depth; fix.diff makes link_add_crs tolerate like the counter walk (compile-validated).

Kernel references

Guest

DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #7: Sat Oct 24 00:08:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/ACHARNESS x86_64

Fix validation

See fix.diff and README.md for the baseline/fixed A/B outputs (run.log / fixed.log).

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.

Fix verification

not_testable

↓ fix.diffper-fix-DF-2390

Confirmed kernel references

Detail

Evidence (decisive lines)

lnkx_boot.log (SSDT LNKX loaded; cant fetch resources for \_SB_.LNKX - AE_AML_INVALID_RESOURCE_TYPE; no panic, boot completes)

PoC changes

ssdt_lnkx.dsl with raw-byte double-DPF _CRS (iasl rejects the macro form) crafted for this batch

Verified recommended fix

see fix.diff

Verdict

Unreachable through firmware on this ACPICA (20251212): a _CRS containing two dependent-function groups is rejected by ACPICAs own resource walk with AE_AML_INVALID_RESOURCE_TYPE before any DragonFly callback runs (acpi_resource.c:429 prints cant fetch resources, the pci_link attach fails with ENXIO, the machine boots normally). The two-walk disagreement in DragonFly code is real (acpi_count_irq_resources tolerates a second START_DEPENDENT via DPF_IGNORE at acpi_pci_link.c:180-186 while link_add_crs panics at :222-226) but can only be reached if ACPICA ever hands such a buffer over. Retained as defense-in-depth; fix.diff makes link_add_crs tolerate like the counter walk (compile-validated).