CVE-2026-72485

CVE-2026-72485 is a memory corruption in the Linux kernel Coresight subsystem where `nr_outconns` is incremented before `devm_krealloc_array()` succeeds, but `coresight_release_platform_data()` unconditionally dereferences entries up to the counter value on cleanup—meaning if allocation fails, the release path walks off the end of a corrupted array and panics. The identical bug appears in both `coresight_add_out_conn()` and `coresight_add_in_conn()`, and the fix in both cases is trivial: move the counter increment after the allocation check. But the trivial fix obscures a deeper structural failure that defenders need to internalize. The duplication tells you this wasn't careless line-by-line coding—it was a mental model error. The developer assumed 'claim your slot early' was good practice, while the cleanup code assumed 'counter equals valid pointer count' was always true. These are opposite assumptions living in the same codebase, and nobody caught the mismatch because allocation logic and cleanup assumptions are reviewed separately. What you should do: First, verify the patch is applied (the increment moves from before the allocation to after the NULL check). Second, audit other Coresight connection management functions for the same pattern—if there's a `nr_inconns` or similar counter, check its ordering. Third, and this is the part most defenders skip: examine `coresight_release_platform_data()` itself. The unconditional iteration `for (i = 0; i < nr_outconns; i++)` is a landmine independent of this CVE. Any future code that corrupts the counter—through this bug, through copy-paste, through drift—triggers the same panic. The proper fix there is either bounds-checking before dereference or switching to an iteration pattern that only touches non-NULL pointers. Finally, recognize this as a class of bug, not an instance. The pattern—counter incremented before allocation, followed by unconditional dereference on cleanup—has appeared in the kernel at least a dozen times under different variable names (`nr_pages`, `count`, `nr_entries`). Each gets its own CVE, each gets its own correct-but-incomplete patch. The systemic exposure isn't just this one vulnerability; it's that the cleanup path itself encodes an invariant ('counter equals valid entries') that nobody states, validates, or checks. Until that invariant becomes machine-checkable, this class will recur. Check your subsystems for the same implicit contract in release paths.

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