CVE-2026-72852 is an integer overflow in darknet's convolutional layer, but framing it as a single bug misses the real problem. The vulnerability stems from a structural divergence between how darknet computes buffer size at allocation time versus how it computes dimensions at runtime. The .cfg parser calculates (c / groups) * n * size * size using 32-bit arithmetic that wraps at INT_MAX, while the actual layer usage computes k as l.size*l.size*l.c / l.groups — mathematically different formulas that produce mismatched results when integer division introduces remainders. The allocation path wraps to a small or zero value; the usage path operates on correct dimensions. This mismatch is where the heap overflow occurs.
The evidence from AddressSanitizer points to gemm_nn_fast as the crash site, which means this isn't layer-specific code pathology — it's a generic memory access that fires whenever the allocation/usage dimensions diverge. In release builds without ASAN, the overflow manifests as glibc heap metadata corruption, confirming writes through an undersized buffer.
What makes this exploitable is the attack surface. A .cfg file is plain text — trivially craftable, no binary parsing required, no .weights file needed. This affects both inference and training modes. The .cfg format has become a de facto standard across the darknet ecosystem (YOLOv4, YOLOv7, various forks), meaning any downstream project parsing untrusted configurations is potentially exposed.
Your priorities: First, audit other layer types in the same codebase — pooling, shortcut, and route layers likely have the same allocation/usage arithmetic divergence. Second, treat .cfg files as untrusted input at your API boundary; darknet currently treats them as trusted. Third, if you're running darknet-based inference in production, inventory every system that loads .cfg files from external sources. The next arithmetic divergence in this codebase may not crash — it may provide controlled memory write primitives.