Darknet: integer overflow in convolutional layer sizing yields a heap overflow from a crafted .cfg

Impact

Darknet sizes the weight and output heap buffers of a convolutional layer by multiplying dimensions read straight from the .cfg in 32-bit int arithmetic, so a configuration whose true product exceeds INT_MAX wraps to a small or zero allocation. The forward pass then re-derives the GEMM dimensions in a different operand order and reads and writes past the end of that buffer; the reporter observed an out-of-bounds read under AddressSanitizer and allocator metadata corruption in a release build, which indicates an out-of-bounds write. Only the .cfg is needed - no matching .weights file - so anywhere a fleet accepts a user-supplied model definition and runs inference or training on it, the file is not just data but a path to memory corruption in the process holding the GPU. On a shared node that process usually has the accelerator device nodes open and whatever dataset mounts the job was given.

Who can reach it

Local: someone who can place or submit a .cfg that a darknet inference or training process then loads. No authentication is involved in the flaw itself; exploitation requires the victim process to load the crafted file (the CVSS vector records UI:P).

What to do

The record names no fixed version - the upstream issue (#148) is the only reference and it does not state a release that carries the fix. Treat this as mitigate-only for now: accept .cfg model definitions only from trusted sources, and run any darknet job that touches tenant-supplied model definitions in a per-tenant sandboxed container so corruption stays inside that job rather than reaching the node.

References