PR #1476 added CL_TYPE_AI_MODEL with magic for GGUF, ONNX and TFLite, and said parsers for these files weren't planned "for now". Before writing any code against your tree I wanted to ask if that's still the case.
I maintain modelvet (https://github.com/tetsuo-ai/modelvet), an MIT licensed C11 library that checks whether a GGUF or safetensors file is structurally safe to parse. A few properties that matter for libclamav:
- vendors as one generated .c/.h pair, no dependencies
- no allocation. Working memory is a single caller supplied buffer with a documented worst case, and a 64 KiB configuration is tested in CI over the whole corpus
- no recursion, every loop bounded, overflow checks on all arithmetic derived from file bytes
- whole-buffer entry point, so it maps directly onto fmap access
Why I think these files are worth parsing: llama.cpp (C++), ollama (Go) and MLX (C++) each wrote their own GGUF reader and each shipped the same class of integer overflow bug (CVE-2024-21825, CVE-2024-23496, CVE-2024-21802, CVE-2024-21836, CVE-2024-23605, CVE-2025-53630 and its bypass CVE-2026-27940, CVE-2026-33298, CVE-2026-7482, CVE-2025-62609). The repo has a regression corpus with one file per advisory, each rejected with a specific error code as a required CI check. There are also differential runs against llama.cpp's loader and the huggingface safetensors crate; modelvet never accepts an input that those reject.
The integration I have in mind looks like the existing format parsers: a cli_parse function behind CL_TYPE_AI_MODEL in the scanners.c switch, reading through ctx->fmap, reporting through cli_append_potentially_unwanted(), gated by DCONF and a scan option. Default off if you prefer.
One more thing from the PR discussion: safetensors was left off the magic list because it has no reliable magic. That's true, but the 8 byte little endian header length plus its 100 MB cap and a leading '{' makes a workable structural test. I can include that too.
If the answer is still no parsers, no problem. If there's a shape you'd accept, tell me and I'll write the PR to match it.
PR #1476 added CL_TYPE_AI_MODEL with magic for GGUF, ONNX and TFLite, and said parsers for these files weren't planned "for now". Before writing any code against your tree I wanted to ask if that's still the case.
I maintain modelvet (https://github.com/tetsuo-ai/modelvet), an MIT licensed C11 library that checks whether a GGUF or safetensors file is structurally safe to parse. A few properties that matter for libclamav:
Why I think these files are worth parsing: llama.cpp (C++), ollama (Go) and MLX (C++) each wrote their own GGUF reader and each shipped the same class of integer overflow bug (CVE-2024-21825, CVE-2024-23496, CVE-2024-21802, CVE-2024-21836, CVE-2024-23605, CVE-2025-53630 and its bypass CVE-2026-27940, CVE-2026-33298, CVE-2026-7482, CVE-2025-62609). The repo has a regression corpus with one file per advisory, each rejected with a specific error code as a required CI check. There are also differential runs against llama.cpp's loader and the huggingface safetensors crate; modelvet never accepts an input that those reject.
The integration I have in mind looks like the existing format parsers: a cli_parse function behind CL_TYPE_AI_MODEL in the scanners.c switch, reading through ctx->fmap, reporting through cli_append_potentially_unwanted(), gated by DCONF and a scan option. Default off if you prefer.
One more thing from the PR discussion: safetensors was left off the magic list because it has no reliable magic. That's true, but the 8 byte little endian header length plus its 100 MB cap and a leading '{' makes a workable structural test. I can include that too.
If the answer is still no parsers, no problem. If there's a shape you'd accept, tell me and I'll write the PR to match it.