CVE-2026-72852: darknet Integer Overflow in Convolutional Layer Buffer Sizing Leads to Heap Buffer Overflow
hank-ai/darknet sizes a convolutional layer's weight and output heap buffers by multiplying configuration fields taken from a .cfg file in unchecked 32-bit int arithmetic. In src-lib/convolutionallayer.cpp, l.nweights is computed as (c / groups) n size size and l.outputs as l.outh l.outw l.outc, and both feed xcalloc directly. A .cfg whose true dimension product exceeds INTMAX wraps to a small or zero value, so the allocation is undersized; for example width and height of 256 with filters of 65536 gives 2^32, which wraps to 0. forwardconvolutionallayer then re-derives the GEMM dimensions with a different operand order, computing k as l.sizel.sizel.c / l.groups where the allocation divided before multiplying, and reads and writes through the undersized buffer. Loading the crafted .cfg for inference or training is sufficient and no valid .weights file is required. The reported proof of concept observed a heap buffer overflow read in gemmnnfast under AddressSanitizer and glibc allocator metadata corruption in a release build of the same input, indicating an out-of-bounds write.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Do not load untrusted or attacker-supplied .cfg files for inference or training; only allow vetted configuration inputs, because loading the crafted .cfg is sufficient to trigger the undersized buffer allocation/overflow.
Event History
Frequently Asked Questions
What input does an attacker need to control?
The attacker needs to provide a crafted Darknet .cfg file with convolutional-layer dimensions whose products exceed INT_MAX. Loading that configuration for either inference or training is sufficient; a valid .weights file is not required.
Which deployments are exposed in practice?
Any Darknet process that loads .cfg files from an untrusted or attacker-controlled source is exposed. The issue is triggered during configuration loading and subsequent convolution processing, rather than requiring a network-facing service.
What runtime evidence may indicate that this issue was triggered?
The reported proof of concept produced a heap buffer overflow read in gemm_nn_fast under AddressSanitizer. In a release build, the same input caused glibc allocator metadata corruption, consistent with an out-of-bounds write.