Can one container see memory that another container freed?

You are safe here, and the reason is more fundamental than anything containers do — the kernel zeroes pages before handing them to a process, full stop.

This is not a container feature. It is a property of the operating system's memory management that predates containers by decades. When any process asks for anonymous memory and first touches it, what it gets is a page of zeros. There is no mechanism by which a normal process receives a page still holding another process's data, because that would be an obvious information leak between ordinary users on a shared machine.

The thing to understand about containers on Linux is that they are not a separate kind of process. Processes in containers are ordinary processes with restricted views of the system through namespaces and limits through control groups. They go through exactly the same allocation path as anything else, and inherit the same guarantee.

So the answer to your specific question is: zeros.

Worth separating that guarantee from the things that genuinely are shared, because your instinct to ask is a good one and there are real answers nearby.

The page cache is shared. Containers reading the same file from the same host filesystem can share cached pages. That is not a leak of freed memory, but it does mean containers are not as independent as they look, and it has been used as a side channel for inferring what another container is doing.

Hardware side channels do not respect namespaces. The processor's caches and branch predictors are shared between everything on the machine. Container boundaries provide no defence against that class of attack, because the boundary is a kernel construct and the leak is below the kernel.

The kernel itself is shared. One kernel vulnerability affects every container on the host simultaneously. This is the fundamental difference from virtual machines and the main reason multi-tenant platforms often use virtualisation underneath containers.

So: memory contents on reallocation, no problem. Isolation strength against a determined co-tenant, weaker than the mental model suggests.

One clarification on over-provisioning, since it is the part that prompted the question and it works differently than people assume.

Over-provisioning does not mean memory shuttles between containers as they allocate and free. Physical pages are assigned when memory is first touched, not when it is requested, and freed memory returns to a general pool. Your container's peak usage does not reserve anything for it afterwards.

What over-provisioning does mean is that if everyone uses their limit at once, something has to give — and what gives is a process being killed by the out-of-memory handler. That is the actual risk of over-provisioning, and it is an availability problem rather than a confidentiality one.

Which is worth knowing because it is the failure people actually meet, usually at three in the morning.

If you are handling something where you do not want secrets sitting in memory longer than necessary at all, the relevant controls are inside your process rather than at the container boundary: locking pages so they are never written to swap, and overwriting buffers before freeing them.

Most cryptographic libraries already do this for key material. It is worth knowing which of your own buffers hold plaintext secrets, because the kernel guarantees nobody else sees them after you free them — it does not stop them sitting in your own address space for hours.