DF-4636 — radeon_acpi: ACPI_OBJECT type confusion + missing Buffer.Length validation in all 4 ATIF/ATCS return parsers

File: sys/dev/drm/radeon/radeon_acpi.c (pass-2 finding) Verification: verbatim-extraction control-flow proof on the DragonFly QEMU guest (methodology identical to accepted finding DF-4605) — BASELINE-CORRUPTS 4/4 rounds, FIXED-CLEAN 4/4 rounds.

What the bug is

All four ATIF/ATCS return-buffer parsers in radeon_acpi.c:

read size = *(u16 *) info->Buffer.Pointer; and then memcpy out of info->Buffer.Pointer without ever checking:

1. info->Type == ACPI_TYPE_BUFFER — if the SBIOS method returns an ACPI_TYPE_INTEGER (perfectly legal for ACPICA — AcpiEvaluateObject externalizes any object type on AE_OK), info->Buffer.Pointer is a union alias of the firmware-chosen 64-bit Integer.Value → wild-pointer kernel read at a firmware-chosen address (verified: si_addr is the integer, verbatim).
2. info->Buffer.Pointer != NULL — a 0-length buffer → NULL+0 fault.
3. info->Buffer.Length >= 2 before the u16 size read → 1-byte OOB read past the ACPICA allocation.
4. info->Buffer.Length >= size before the memcpy → up to sizeof(struct atif/atcs_*output) (8–13) bytes heap OOB read past the ACPICA allocation when the buffer's own size header lies.

Trigger: any SBIOS/firmware that implements ATIF/ATCS with a malformed return (bug or malice). Parsed values feed internal notification config and radeon_set_backlight_level() (arithmetic only — no indexing), so the impact ceiling is kernel-mode wild/OOB read → panic (DoS), not escalation.

How to reproduce

scp -F dfbsd-qemu/config extract_and_test.sh fix.diff dfbsd:/tmp/df4636_dir/
./dfbsd-qemu/vm.sh run_root 'sh /tmp/df4636_dir/extract_and_test.sh'

The script (single-tenant guest must be up: dfbsd-qemu/vm.sh status):

1. sha256-gates the guest's /usr/src/sys/dev/drm/radeon/radeon_acpi.c and .h against the audited tree (byte-identical),
2. awk-extracts the four parsers verbatim (plus *_call and the *_parse_* helpers),
3. compiles them against a faithful ACPICA shim (union layout printed at runtime: offsetof(Integer.Value)==offsetof(Buffer.Pointer)==8) with a mock AcpiEvaluateObject returning firmware-chosen objects,
4. drives 5 fault fixtures + 1 well-formed control, 4 iterations each, in forked children with a SIGSEGV tracer printing exact si_addr,
5. re-extracts from a copy patched with fix.diff and repeats everything.

Expected output (decisive)

PROOF-RESULT: BASELINE-CORRUPTS (5/5 fixtures SIGSEGV 4/4 iterations, control parses)
PROOF-RESULT: FIXED-CLEAN (no faults, control still parses)

with fault-address distribution over 4 rounds (see run.log):

Honest scope caveat

The in-kernel end-to-end path could not run on this guest: it has no AMD GPU (virtio-vga) and radeon is not built into any guest kernel config. The proof is at the verbatim-extraction level against the byte-identical shipped source (deterministic, source-faithful). In the kernel, every fault observed here is a kernel-mode fault in ACPICA notify/init context → panic.

Fix

fix.diff (git-apply --check clean against sys/): add a Type/NULL/Length>=2 guard after each if (!info) and require info->Buffer.Length >= size before each memcpy/parse. Validated in the same harness: FIXED variant rejects all malformed fixtures with -EINVAL while the well-formed control still parses.

DF-4636 VERDICT — radeon_acpi ATIF/ATCS parser type-confusion / OOB read

Status: reproduced (verbatim-extraction control-flow proof on the guest) Impact: dos (firmware-controlled kernel wild-pointer/OOB read → panic) Confidence: certain

1. Root cause (source-faithful)

sys/dev/drm/radeon/radeon_acpi.c has four parsers of ACPI method return buffers — radeon_atif_verify_interface (:198-231), radeon_atif_get_notification_params (:245-294), radeon_atif_get_sbios_requests (:307-334), radeon_atcs_verify_interface (:480-512). Each does, with zero validation of the returned ACPI_OBJECT:

size = *(u16 *) info->Buffer.Pointer;   /* :212, :259, :318, :494 */
...
size = min(sizeof(output), size);
memcpy(&output, info->Buffer.Pointer, size);   /* :220, :267, :326, :502 */

radeon_atif_call/radeon_atcs_call (:103-138, :414-449) return buffer.Pointer whenever AcpiEvaluateObject does not fail. ACPICA (nsxfeval.c:536-599) externalizes any return object type on AE_OK — an SBIOS ATIF/ATCS method that returns an Integer, a zero-length Buffer, or a Buffer whose in-band size header exceeds the allocation reaches the parsers unchoked. In union acpi_object (actypes.h:1077-1098) Buffer.Pointer and Integer.Value share offset 8, so a returned INTEGER makes the parser dereference the firmware-chosen 64-bit value as a kernel pointer. This is the radeon twin of pass-1 amdgpu finding DF-1750 (same defect, different file — this file was clean in pass 1).

Threat model: the input is platform firmware, not an unprivileged user. A malicious or buggy SBIOS (or crafted ACPI tables, which require root/loader control to install) gets a kernel-mode read at a chosen 64-bit address, or a 1..13-byte heap OOB read past an M_ACPICA allocation; any fault lands in ACPICA notify-dispatch or driver-init context → kernel panic. Parsed output feeds internal notification config masks and radeon_set_backlight_level() (atombios arithmetic only, atombios_encoders.c:87-112 — no indexing), so there is no escalation sink; the impact ceiling is DoS. Severity Medium (matches DF-1750's calibration for the identical amdgpu defect).

2. Proof (what was run, what was seen)

Methodology identical to accepted DF-4605: verbatim extraction + faithful shim.

• Guest /usr/src/sys/dev/drm/radeon/radeon_acpi.c sha256 794cb6c29cb9e9fd17d4c826e86389ecb44a778e1f80ace15f7cc3e1a3410cb1 — byte-identical to the audited tree (script aborts otherwise); same for radeon_acpi.h. The four parsers + 5 helpers are awk-extracted verbatim (258 lines) and compiled on the guest (cc 8.3) against an actypes.h-faithful union acpi_object (aliasing confirmed at runtime: offsetof(Integer.Value)=8 offsetof(Buffer.Pointer)=8) with a mock AcpiEvaluateObject that returns AE_OK with firmware-chosen objects, exactly as ACPICA does after externalization.

Result (run.log, 4 rounds, 5 fault fixtures × 4 iterations each + control):

PROOF-RESULT: BASELINE-CORRUPTS in 4/4 full rounds. Every fault address is exactly the firmware-supplied value / exactly one guard page past the ACPI allocation — deterministic, no heuristics.

Iterations fixed during verification (all mine, not the kernel's): 1. sha256 typo in the gate (my transcription), 2. extraction bugs: indented # define lines in radeon_acpi.h missed by the grep; a line-range sed of radeon.h swallowed a trailing /* — both replaced by pattern-bounded extraction, 3. first wild-address values (0x4141414100000000) were non-canonical x86-64 addresses → #GP reports si_addr=0x0; switched to canonical values so si_addr prints the dereferenced pointer verbatim.

3. Fix validation

fix.diff (git-apply --check clean against the unmodified sys/ tree): after each if (!info) the parsers now require info->Type == ACPI_TYPE_BUFFER, info->Buffer.Pointer != NULL, info->Buffer.Length >= 2, and each parse is bounded by info->Buffer.Length >= size before any memcpy. The same harness compiled from the fix.diff-patched extraction returns -EINVAL for all five malformed fixtures with no fault in 4/4 rounds, while the well-formed control still parses (PROOF-RESULT: FIXED-CLEAN ×4 in run.log).

Kernel-level build/run validation is not possible on this guest (no AMD GPU; radeon absent from the guest kernel config and module set), so fix_status is inconclusive with the harness-level validation as evidence — same posture as DF-4605.

4. Why this is a real finding and not noise

• The identical defect in the sibling amdgpu driver is an accepted pass-1 finding (DF-1750); this file was audited clean in pass 1 and the pass-2 deeper look found the radeon twin.
• ACPICA externalizes non-BUFFER returns on success (nsxfeval.c:536-599 read line-by-line during this verification) — the "firmware will always return a buffer" assumption is unenforced by anything in the path.
• Every code path is firmware-data-driven with zero validation before the first dereference; the control fixture proves the extraction reproduces the real parser semantics (well-formed input parses to err=0).

Guest stayed up throughout (userland harness only); no reset required.

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.