llama.cpp EUVD-2026-110571

Exploitation requires a victim to load an attacker-crafted GGUF model file into a vulnerable llama.cpp build (b5854 up to but not including b11275). The specific precondition is a GGUF tensor whose computed ggml_nbytes is near SIZE_MAX (the patch's test uses F32 with ne=[4, 2^30-1, 2^30+1, 1], yielding 2^64-16) so that GGML_PAD's addition of (alignment-1) wraps the padded size to zero, defeating the CVE-2025-53630 size check and producing an undersized data blob. Exploitation is LIMITED by the local attack vector and required user interaction (UI:P) - the malicious file must be delivered to and opened/parsed by the victim; there is no remote or network trigger. No authentication is required (PR:N), but the practical gate is social delivery of the model file. Impact is bounded to out-of-bounds reads by consumers (availability/crash, limited info disclosure), not code execution per the available data.

This is a genuine but moderate-priority memory-safety flaw, not a top-tier emergency. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P) scores 6.9 (medium), and critically the attack vector is LOCAL with passive user interaction - the victim must load an attacker-supplied GGUF file - so this is not a remotely-triggerable network bug despite being unauthenticated. All real-world signals align toward lower urgency: EPSS is 0.13% (2nd percentile), SSVC reports Exploitation=none, Automatable=no, and Technical Impact=partial, and the vulnerability is NOT on the CISA KEV list. The vuln.today priority is 'this_month' rather than act_now/emergency, consistent with these signals. The primary impact is availability (VA:H - out-of-bounds reads by downstream consumers of the undersized data blob, leading to crashes) with only low confidentiality exposure (VC:L) and no integrity impact. There are no strongly conflicting signals here - low EPSS, no KEV, and non-automatable SSVC all agree this is a patch-in-routine-maintenance issue rather than a fire. The one nuance: the triggering mechanism IS well understood from the patch diff (GGML_PAD adds alignment-1 to nbytes; near SIZE_MAX this wraps to 0, nullifying the CVE-2025-53630 size check), so this is a confirmed, reproducible bug with a vendor test case, not a theoretical one.

An attacker publishes a malicious GGUF model file (e.g., on a model-sharing hub) whose tensor dimensions are chosen so ggml_nbytes approaches SIZE_MAX and the padded size wraps to zero; a victim downloads and loads it into a vulnerable llama.cpp build (b5854 up to b11275). During parsing the bypassed size check allocates an undersized data blob, and subsequent tensor access performs out-of-bounds reads, crashing the process or leaking adjacent memory. The vendor's patch ships a handcrafted test case (TENSORS_NBYTES_PAD_WRAP) demonstrating the overflow, but no weaponized exploit is confirmed.