A 65-byte model file can bring the popular Llama CPP inference engine to an abrupt halt. The tiny payload triggers a division-by-zero inside the parser, producing a SIGFPE crash.
Why the crash matters
What went wrong
The parser reads model metadata into C++ structures and checks that each tensor dimension is “non-negative.” Zero satisfies that condition, so the check passes. The next line of code then uses the dimension as a divisor in a calculation that assumes the value is positive. When the dimension is zero, the division throws a floating-point exception (SIGFPE) and terminates the program.
The validation covered only half of the needed invariant: it blocked negative values but ignored zero, which is just as unsafe for the subsequent arithmetic.
What developers should do
- Treat model files like binaries. Loading a model parses raw bytes into memory structures, a classic boundary where unchecked data can crash the process or do worse.
- Avoid partial checks. A condition that covers only part of the required invariant gives a false sense of security. Here, “non-negative” was insufficient; the code needed “positive.”
- Question assumptions after each check. When a bounds test appears, verify that the following code does not rely on a stricter property.
- Employ fuzzing tools. The author uncovered the bug by running libFuzzer with AddressSanitizer, which mutates inputs and flags illegal operations like division by zero.
How the fix was applied
The fix adds a guard that skips the overflow calculation when a dimension equals zero. This tiny conditional preserves support for legitimate zero-sized tensors—used in some model variants for optional features—while eliminating the crash path.
Takeaway: A single 65-byte file can shut down a widely deployed inference engine; thorough validation and systematic fuzzing keep model loaders safe.
Source: https://dev.to/harrisonsec/your-model-file-is-untrusted-input-1eap
