CVE-2026-74452

This CVE exposes a relational reasoning failure in the Panthor GPU driver's firmware parser. The code validated that header fields exist and are well-formed, but never checked that the derived data size is safe relative to the destination buffer. The fix adds `section_size` as an explicit ceiling on `data.size` at the parsing boundary — this is the correct remediation, and you should apply it. The more interesting question is the memset path. The patch does not directly guard the subtraction `panthor_kernel_bo_size(section->mem) - section->data.size`. If `data.size` exceeds the BO size, this underflows to a massive unsigned value, causing catastrophic out-of-bounds zeroing. However, if `data.size <= section_size` by construction and the BO is allocated with at least `section_size` bytes, the memset path becomes structurally unreachable — the relational fix upstream makes the underflow impossible to trigger. This appears to be why the patch author left the memset line untouched: the upstream fix implicitly secures it. The actionable question for your audit: verify that the BO allocation path always produces a buffer at least as large as `section_size`. This is currently an implicit invariant, not an explicit assertion. If your codebase modification or a future refactor changes how BO sizing works, the memset path could become reachable again. Add an explicit assertion to codify this relationship — do not rely on implicit structural guarantees that live only in the reasoning of whoever last touched this code. This vulnerability fits a recurring pattern in kernel firmware parsing: validate format, derive size, fail to relational-check against destination. The institutional gap is that the kernel's firmware parsing interfaces do not encode size relationality as a first-class invariant, forcing every driver to re-invent this reasoning. Your fix is correct, but document the invariant explicitly to prevent future decay.

Reviewed through automated stages and approved by a human before publication.