GPU VulnDB

Database/AI/ML frameworks & serving

llama.cpp: oversized seq_id in a saved slot file leaks heap memory past the cells array

CVE-2026-43630AI/ML frameworks & servingcurated

Impact

Builds b5702 through b7653 read past the end of the allocated cells array when restoring recurrent memory state from a slot file, leaking heap bytes - including pointer values - into the server's logs. The leaked pointers defeat ASLR on the inference host and make a follow-on memory-corruption attempt materially easier. On a GPU node this is an information-disclosure step rather than an immediate takeover, but the slot save directory is often a shared volume or a host path mounted into the serving container, and the logs it leaks into are frequently shipped to a central collector where other tenants or lower-privileged operators can read them. Exploitation requires the attacker to already have write access to the slot save directory.

Who can reach it

Anyone who can write a file into the llama.cpp slot save directory - a co-tenant sharing that volume, a compromised sidecar, or a user of an API that persists slots on their behalf - then triggers a restore. The record indicates no authentication to the server itself is needed (PR:N) once the file is in place.

What to do

Upgrade llama.cpp past build b7653 to a build containing commit f93c09e and restart the server process. If you cannot rebuild immediately, take write access to the slot save directory away from anything but the server itself and stop exposing the restore endpoint to tenants; also scrub existing logs, since already-leaked pointer values stay valid for the lifetime of a running process.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.