Talos Vulnerability Report

SUMMARY

A heap-based buffer overflow vulnerability exists in the GGUF library header.n_kv functionality of llama.cpp Commit 18c2e17. A specially crafted .gguf file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

CONFIRMED VULNERABLE VERSIONS

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

llama.cpp Commit 18c2e17

PRODUCT URLS

llama.cpp - https://github.com/ggerganov/llama.cpp

CVSSv3 SCORE

8.8 - CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE

CWE-190 - Integer Overflow or Wraparound

DETAILS

LLaMA.cpp is the cpp implementation for running the LLaMA. This project relies on the ggml library, that is a tensor library with several functionalities.

The LLaMA project and many other relies on the GGUF file format. GGUF is a popular file format for storing LLM model representations. In this library the function that parses the .gguf file is gguf_init_from_file:

struct gguf_context * gguf_init_from_file(const char * fname, struct gguf_init_params params) {
    FILE * file = fopen(fname, "rb");
    if (!file) {
        return NULL;
    }
    [...]
    struct gguf_context * ctx = GGML_ALIGNED_MALLOC(sizeof(struct gguf_context));

    // read the header
    {
        [...]

        ctx->kv    = NULL;
        ctx->infos = NULL;
        ctx->data  = NULL;

        ok = ok && gguf_fread_el(file, &ctx->header.version,   sizeof(ctx->header.version),   &offset);
        ok = ok && gguf_fread_el(file, &ctx->header.n_tensors, sizeof(ctx->header.n_tensors), &offset);
        ok = ok && gguf_fread_el(file, &ctx->header.n_kv,      sizeof(ctx->header.n_kv),      &offset);

        [...]
    }
    [...]
    // read the kv pairs
    {
[1]     ctx->kv = malloc(ctx->header.n_kv * sizeof(struct gguf_kv));

        for (uint64_t i = 0; i < ctx->header.n_kv; ++i) {
[2]         struct gguf_kv * kv = &ctx->kv[i];

[3]         ok = ok && gguf_fread_str(file, &kv->key,                    &offset);
            ok = ok && gguf_fread_el (file, &kv->type, sizeof(kv->type), &offset);
            [...]
        }
        [...]
    }
    [...]
}

We will focus on the kv parsing part. At [1] the spaces for the specified ctx->header.n_kv, value parsed from the provided file, is used to allocate the correct number of gguf_kv elements. Then it is fetched from the file, for each kv element, its key and its type. At [1], the ctx->header.n_kv is an arbitrary uint64_t value, and the sizeof(struct gguf_kv) is 48 bytes. The multiplication between the two can lead to an integer overflow, this would results in allocating less elements than required. Then at [2] the i-th element of the allocated array is fetched, and then used at [3], this could lead to a heap-based buffer overflow in the gguf_fread_str function writing the pointer to a string in kv->key.

Crash Information

=================================================================
==3991406==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000003c59 at pc 0x7f0858e11559 bp 0x7ffc53e68c60 sp 0x7ffc53e68410
WRITE of size 8 at 0x603000003c59 thread T0
    #0 0x7f0858e11558 in __interceptor_fread ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1025
    #1 0x55d14690937c in gguf_fread_el /home/vagrant/llama.cpp/ggml.c:18652
    #2 0x55d14690a263 in gguf_init_from_file /home/vagrant/llama.cpp/ggml.c:18767
    #3 0x55d1469a97e9 in llama_model_loader::llama_model_loader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, llama_model_kv_override const*) (/home/vagrant/llama.cpp/main+0x1b17e9)
    #4 0x55d146955592 in llama_model_load /home/vagrant/llama.cpp/llama.cpp:3792
    #5 0x55d146974355 in llama_load_model_from_file /home/vagrant/llama.cpp/llama.cpp:9291
    #6 0x55d146a931b4 in llama_init_from_gpt_params(gpt_params&) common/common.cpp:1105
    #7 0x55d14683f8b1 in main examples/main/main.cpp:187
    #8 0x7f08588d5d09 in __libc_start_main ../csu/libc-start.c:308
    #9 0x55d146839f49 in _start (/home/vagrant/llama.cpp/main+0x41f49)

0x603000003c59 is located 0 bytes to the right of 25-byte region [0x603000003c40,0x603000003c59)
allocated by thread T0 here:
    #0 0x7f0858e7d037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x55d1469094af in gguf_fread_str /home/vagrant/llama.cpp/ggml.c:18663
    #2 0x55d146909ed8 in gguf_init_from_file /home/vagrant/llama.cpp/ggml.c:18753
    #3 0x55d1469a97e9 in llama_model_loader::llama_model_loader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, llama_model_kv_override const*) (/home/vagrant/llama.cpp/main+0x1b17e9)
    #4 0x55d146955592 in llama_model_load /home/vagrant/llama.cpp/llama.cpp:3792
    #5 0x55d146974355 in llama_load_model_from_file /home/vagrant/llama.cpp/llama.cpp:9291
    #6 0x55d146a931b4 in llama_init_from_gpt_params(gpt_params&) common/common.cpp:1105
    #7 0x55d14683f8b1 in main examples/main/main.cpp:187
    #8 0x7f08588d5d09 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1025 in __interceptor_fread
Shadow bytes around the buggy address:
  0x0c067fff8730: fd fd fa fa 00 00 00 00 fa fa 00 00 00 02 fa fa
  0x0c067fff8740: 00 00 00 07 fa fa fd fd fd fd fa fa fd fd fd fd
  0x0c067fff8750: fa fa 00 00 00 05 fa fa fd fd fd fd fa fa fd fd
  0x0c067fff8760: fd fd fa fa 00 00 00 03 fa fa 00 00 00 00 fa fa
  0x0c067fff8770: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fa fa
=>0x0c067fff8780: fa fa 00 00 00 00 fa fa 00 00 00[01]fa fa fa fa
  0x0c067fff8790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff87a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff87b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff87c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff87d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==3991406==ABORTING

VENDOR RESPONSE

Databricks has independently reported this vulnerability concurrently with our own discovery.

We have not received a response from the vendor, however, we confirmed that this vulnerability has been fixed.

TIMELINE

2024-01-29 - Initial Vendor Contact
2024-01-29 - Vendor Patch Release
2024-01-30 - Vendor Disclosure
2024-02-26 - Public Release