INF04: Host and accelerator memory isolation failure

EvidenceAdvisory-backed

ImpactCConfidentiality

OWASP AISVS 1.014.2.4 closestClosest requirements, see mapping

AttackerA3, internal workload

What it is

Performance work pushes serving toward shared memory segments, host IPC and reused device memory. Each crosses a process boundary on purpose, and bounds checking on shared-memory registration is a recurring source of memory-safety defects in native code.

This page covers boundaries enforced by the operating system, driver, device or orchestrator. Stale data left by the serving system's own request bookkeeping, including between its prefill and decode workers, is INF11.

Variants and records

Cross-process GPU leakage

On some GPUs, one program can read leftover data from another program's GPU memory. Researchers recovered another user's LLM response this way, across process and container boundaries.

Advisory-backed
LeftoverLocals, CVE-2023-4969. Affected AMD, Apple, Qualcomm and some Imagination GPUs; NVIDIA reported it was not affected. A proof of concept, with no real-world exploitation reported.

Host namespace sharing

Kubernetes settings such as hostIPC and privileged let a pod see or touch the host. They remove the walls between workloads that the rest of the design assumes.

Architectural
No single record. It is a configuration pattern.

One rule. Reject privileged and host-namespace pods unless justified, and review shared-memory registration like any parser of untrusted lengths.

Check your stack

No inference workload sets hostIPC, hostNetwork, hostPID or privileged without a written reason.
You know which shared-memory segments exist at runtime and their permissions.
Your device-buffer reuse policy between tenants is written down.
You know who on the fabric can write into registered memory regions.
You know which GPU sharing mode (MPS, time slicing, MIG) each node uses and what isolation it gives.
You have asked whether one process can read another's leftover device memory on your GPU class. We know of no public production case, but the question is open.

Tests

Each test has a positive control: a condition under which it must fail. A test that cannot fail proves nothing. These are procedures. Hedgerow has not run them.

Admission

Do: Submit a pod with hostIPC or privileged to the cluster.
Pass: Admission rejects it.
Must fail when: The admission policy is disabled in staging.

Segment permissions

Do: List shared-memory segments and permissions on a running node.
Pass: Each is scoped to its pod.
Must fail when: A segment is created world-readable.

Device memory remanence

Do: In process A write a canary to device memory and exit; in process B read uninitialized allocations.
Pass: No canary appears.
Must fail when: Run on a GPU class shown to leak local memory.

Mapping to AISVS, ATLAS and CWE

Framework	Mapping
OWASP AISVS 1.01	Closest: 4.2.4 (accelerator memory isolated between workloads, with memory sanitization between jobs, level 3), 4.1.1 (models execute in isolated sandboxes) and 4.3.3 (inference runtimes enforce process, memory and file isolation).
MITRE ATLAS 5.6.0	No technique fits well.
CWE	CWE-226 Sensitive Information in Resource Not Removed Before Reuse (Hedgerow proposal for remanence), and CWE-250 Execution with Unnecessary Privileges.

Controls

Reject privileged and host-namespace-sharing pods at admission unless explicitly justified.
Scope memory-backed volumes to the pod.
Treat native shared-memory registration paths as parsers of untrusted length fields.

What this page does not claim

The tests have not been run by Hedgerow.
Standards mappings reflect the versions named and may change as they do.
A cited record shows the mechanism occurred in at least one implementation. It does not say any given system is affected.

Sources

INF04. Host and accelerator memory isolation failure