Description

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/convolutional_layer.cpp, l.nweights is computed as (c / groups) * n * size * size and l.outputs as l.out_h * l.out_w * l.out_c, and both feed xcalloc directly. A .cfg whose true dimension product exceeds INT_MAX 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. forward_convolutional_layer then re-derives the GEMM dimensions with a different operand order, computing k as l.size*l.size*l.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 gemm_nn_fast under AddressSanitizer and glibc allocator metadata corruption in a release build of the same input, indicating an out-of-bounds write.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-20T19:17:00.830Z",
  "pubdate": "2026-08-20T19:17:00.830Z",
  "executiveSummary": "An integer overflow vulnerability exists in hank-ai/darknet, specifically within the convolutional layer initialization logic located in src-lib/convolutional_layer.cpp.\nThe vulnerability is triggered via unchecked 32-bit integer arithmetic when calculating memory buffer sizes from configuration fields defined in a user-supplied .cfg file.\nBy supplying malicious configuration dimensions whose product exceeds INT_MAX, the calculated allocation size wraps around to a small or zero value.\nThis results in a critically undersized heap buffer allocation via xcalloc, while subsequent operations process larger dimensions and perform out-of-bounds read and write operations.\nThe impact of this vulnerability includes heap buffer overflow reads, heap metadata corruption leading to potential arbitrary code execution, and application crashes.\nAttackers can achieve exploitation simply by loading a crafted .cfg file during inference or training, requiring no valid .weights file or authentication.\nThe risk is high for systems processing untrusted model configurations, as local execution or integrated processing pipelines are directly exposed to memory corruption.",
  "technicalDetails": "The vulnerability resides in the convolutional layer initialization and execution routines within src-lib/convolutional_layer.cpp in hank-ai/darknet.\nThe root cause is the use of unchecked 32-bit integer arithmetic to compute heap buffer sizes for convolutional layer weights and outputs based on parameters read from a .cfg file.\nSpecifically, l.nweights is computed using the expression (c / groups) * n * size * size, and l.outputs is computed using l.out_h * l.out_w * l.out_c.\nBoth computed values are passed directly to xcalloc without verifying if an integer overflow has occurred.\nWhen a specially crafted .cfg file defines dimensions that cause the true product to exceed INT_MAX, the integer wraps around to a small or zero value.\nFor example, specifying a width and height of 256 with 65536 filters results in a product of 2^32, which wraps to 0 and allocates an undersized buffer.\nDuring execution in forward_convolutional_layer, the application re-derives General Matrix Multiplication (GEMM) dimensions using a different operand order, computing k as l.size*l.size*l.c / l.groups where the allocation divided before multiplying.\nBecause the allocation size does not match the iteration and processing bounds, the application reads and writes past the boundaries of the undersized heap buffer.\nAn attacker exploits this by supplying a crafted .cfg file for model inference or training.\nLoading the configuration is sufficient to trigger the flaw, and no valid .weights file is required.\nObserved proof of concept behavior includes a heap buffer overflow read in gemm_nn_fast under AddressSanitizer and glibc allocator metadata corruption in a release build, confirming out-of-bounds write capabilities and subsequent memory safety violations."
}