Bug#1109124: llama.cpp: CVE-2025-53630
Hi Christian, On Sun, Jul 13, 2025 at 08:45:02AM +0200, Christian Kastner wrote: > Hi Salvatore, > > On 2025-07-13 07:49, Salvatore Bonaccorso wrote: > > On Sat, Jul 12, 2025 at 12:04:34AM +0200, Christian Kastner wrote: > >> Nevertheless, I really need to figure out a better way to deal with > >> llama.cpp, whisper.cpp, and ggml triad. Re-embedding isn't an option as > >> the ggml build is already pretty complicated by itself, adding another > >> layer would be a pain. > > > > Thanks. The gguf.cpp as emmbedded in llama.cpp is compiled and used, > > is that correct? Do we use the external ggml in the system? > > That's how llama.cpp is primarily developed distributed, but for Debian > we ignore the embedded version and build a standalone src:ggml. Ack. > This is mainly because the ggml build is already quite complex (multiple > CPU and GPU backends), and redundant between llama.cpp and whisper.cpp > (still in NEW). > > llama.cpp and whisper.cpp should eventually +ds clean their embedded > copies, I just want to wait a bit more to see if a standalone src:ggml > remains viable. Ack, I think that would clarify the situation bit more, but balance it with feasibility. Regards, Salvatore
Bug#1109124: llama.cpp: CVE-2025-53630
Hi Salvatore, On 2025-07-13 07:49, Salvatore Bonaccorso wrote: > On Sat, Jul 12, 2025 at 12:04:34AM +0200, Christian Kastner wrote: >> Nevertheless, I really need to figure out a better way to deal with >> llama.cpp, whisper.cpp, and ggml triad. Re-embedding isn't an option as >> the ggml build is already pretty complicated by itself, adding another >> layer would be a pain. > > Thanks. The gguf.cpp as emmbedded in llama.cpp is compiled and used, > is that correct? Do we use the external ggml in the system? That's how llama.cpp is primarily developed distributed, but for Debian we ignore the embedded version and build a standalone src:ggml. This is mainly because the ggml build is already quite complex (multiple CPU and GPU backends), and redundant between llama.cpp and whisper.cpp (still in NEW). llama.cpp and whisper.cpp should eventually +ds clean their embedded copies, I just want to wait a bit more to see if a standalone src:ggml remains viable. Best, Christian
Bug#1109124: llama.cpp: CVE-2025-53630
Hi Christian, On Sat, Jul 12, 2025 at 12:04:34AM +0200, Christian Kastner wrote: > On 2025-07-11 21:19, Salvatore Bonaccorso wrote: > > The following vulnerability was published for llama.cpp. > > > > CVE-2025-53630[0]: > > | llama.cpp is an inference of several LLM models in C/C++. Integer > > | Overflow in the gguf_init_from_file_impl function in > > | ggml/src/gguf.cpp can lead to Heap Out-of-Bounds Read/Write. > > This is a bit of an interesting situation as the fix went into the ggml > embedded into llama.cpp, but it hasn't been synced up to main ggml yet. > And because there is also an ABI break, the newest llama.cpp doesn't > build with the old ggml. > > I'll ask upstream for a sync, and to automatically do so in future if a > CVE gets reported. > > Nevertheless, I really need to figure out a better way to deal with > llama.cpp, whisper.cpp, and ggml triad. Re-embedding isn't an option as > the ggml build is already pretty complicated by itself, adding another > layer would be a pain. Thanks. The gguf.cpp as emmbedded in llama.cpp is compiled and used, is that correct? Do we use the external ggml in the system? Regards, Salvatore
Bug#1109124: llama.cpp: CVE-2025-53630
On 2025-07-11 21:19, Salvatore Bonaccorso wrote: > The following vulnerability was published for llama.cpp. > > CVE-2025-53630[0]: > | llama.cpp is an inference of several LLM models in C/C++. Integer > | Overflow in the gguf_init_from_file_impl function in > | ggml/src/gguf.cpp can lead to Heap Out-of-Bounds Read/Write. This is a bit of an interesting situation as the fix went into the ggml embedded into llama.cpp, but it hasn't been synced up to main ggml yet. And because there is also an ABI break, the newest llama.cpp doesn't build with the old ggml. I'll ask upstream for a sync, and to automatically do so in future if a CVE gets reported. Nevertheless, I really need to figure out a better way to deal with llama.cpp, whisper.cpp, and ggml triad. Re-embedding isn't an option as the ggml build is already pretty complicated by itself, adding another layer would be a pain. Best, Christian
Bug#1109124: llama.cpp: CVE-2025-53630
Source: llama.cpp Version: 5760+dfsg-4 Severity: grave Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team Hi, The following vulnerability was published for llama.cpp. CVE-2025-53630[0]: | llama.cpp is an inference of several LLM models in C/C++. Integer | Overflow in the gguf_init_from_file_impl function in | ggml/src/gguf.cpp can lead to Heap Out-of-Bounds Read/Write. This | vulnerability is fixed in commit | 26a48ad699d50b6268900062661bd22f3e792579. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2025-53630 https://www.cve.org/CVERecord?id=CVE-2025-53630 [1] https://github.com/ggml-org/llama.cpp/security/advisories/GHSA-vgg9-87g3-85w8 [2] https://github.com/ggml-org/llama.cpp/commit/26a48ad699d50b6268900062661bd22f3e792579 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
