In a shared GPU environment, uninitialised output can expose data from earlier GPU tensors. This is a kernel-memory correctness concern, distinct from whether a prefix cache is intentionally shared across tenants.
What deployment does this concern?
Component and scope: Integer truncation in specific GGUF dequantisation kernels.
Affected versions / scope: Vendor header: ≥ 0.5.5; affected kernel path and tensor shape are prerequisites.
Vendor remediation: Current vendor patched-version field: ≥ 0.24.0
The model and execution path use the affected GGUF dequantisation kernels with dimensions that encounter integer truncation. The defect can leave part of an allocated output tensor uninitialised.
Vendor response and practical action
The current vendor advisory lists 0.24.0 as patched. Upgrade the affected runtime and evaluate model-format and tenant-isolation choices. Do not replace the current primary patch statement with an older registry value.
Treat the vendor notice as the starting point for an applicability decision. Identify the installed artifact and configuration, document whether the prerequisite exists, and assign an owner to any required change. A public advisory does not establish that your installation was exposed or that a managed service shares the same condition.
What clients can learn
Per-request cache salting addresses cache reuse and timing inference between trust groups. It does not repair this kernel defect or establish process and GPU memory isolation by itself.
A useful evaluation result connects a named control to evidence from the actual deployment. Keep the provider's statement, your effective configuration and a relevant demonstration together. If the result depends on a feature being disabled or a network being isolated, retain that fact with the version number so a later change triggers review.
Questions to take to your provider
- Are GGUF models and the affected kernels used?
- Which tenants share a process, GPU and memory allocator?
- Is the deployed version consistent with the current vendor patch statement?
- What isolation evidence covers kernels separately from prefix-cache policy?
Use the six-page evaluation worksheet to record evidence, ownership and actions. Continue with Running LLM inference in production: security, isolation and capacity for the wider evaluation context.
Technical detail: evidence and identifier limits
The advisory is not a general finding that every user's KV cache is left unwiped. It concerns particular dequantisation kernels and partially uninitialised output tensors.
- Primary identifier: GHSA-5jv2-g5wq-cmr4; vendor mapping CVE-2026-53923.
- An older registry patch value differs; the current primary advisory's ≥ 0.24.0 statement is retained.
Evidence label: security advisory. Source-review date: 2026-10-07. Source publication or event date: 2026-06-11. These dates do not change merely because this article is rebuilt.