Skip to main content
CVE Vulnerability Database

CVE-2024-3056: Podman IPC Resource Exhaustion DoS Flaw

CVE-2024-3056 is a denial of service vulnerability in Podman that enables attackers to exhaust system memory through IPC resource manipulation. This article covers technical details, affected versions, impact, and mitigation.

Published:

CVE-2024-3056 Overview

CVE-2024-3056 is a resource exhaustion vulnerability [CWE-400] in Podman that allows an attacker to trigger a memory-based denial of service. A specially crafted container sharing an Inter-Process Communication (IPC) namespace with another container can allocate large numbers of IPC resources in /dev/shm. Because these resources persist as long as a non-malicious container keeps the IPC namespace open, repeated restarts of the malicious container accumulate memory usage until the host is exhausted. The flaw affects Podman across Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and Fedora distributions.

Critical Impact

A container configured with --restart=always can repeatedly exhaust host memory through orphaned IPC resources, resulting in a system-wide denial of service.

Affected Products

  • Podman (podman_project)
  • Red Hat Enterprise Linux 8 and 9
  • Red Hat OpenShift Container Platform 4
  • Fedora 40

Discovery Timeline

  • 2024-08-02 - CVE-2024-3056 published to the National Vulnerability Database (NVD)
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-3056

Vulnerability Analysis

The vulnerability stems from how Podman manages the lifecycle of IPC resources allocated within a shared IPC namespace. When two or more containers share an IPC namespace, resources such as POSIX shared memory objects created under /dev/shm are tied to the namespace rather than to any individual container's cgroup. A malicious container can allocate resources until it triggers the out-of-memory (OOM) killer. The cgroup for the killed container is removed, but the shared memory objects remain because a second container is still holding the namespace open.

If the malicious container is configured to restart automatically, the process repeats on each restart. Each iteration adds to the accumulated memory held by orphaned IPC resources. Over time, the host runs out of memory and becomes unresponsive.

Root Cause

The root cause is uncontrolled resource consumption [CWE-400] in the interaction between container lifecycle management and IPC namespace resource cleanup. Podman does not enforce a per-container or per-namespace ceiling on IPC allocations in /dev/shm, and orphaned objects are not reclaimed when their originating container terminates.

Attack Vector

An attacker requires the ability to run a container that shares an IPC namespace with at least one other container on the host. The attacker configures the malicious container with an always-restart policy, for example podman run --restart=always --ipc=container:<victim>. The container then allocates shared memory objects in /dev/shm until it is OOM-killed and restarts, repeating the exhaustion loop.

For technical details on the resource-cleanup behavior, see the Red Hat Bugzilla Report #2270717.

Detection Methods for CVE-2024-3056

Indicators of Compromise

  • Rapid growth of files and objects under /dev/shm that persist after container termination.
  • Repeated OOM-killer events in dmesg or journalctl correlating with a container restart loop.
  • Containers running with --restart=always combined with --ipc=container:<name> or --ipc=shareable.
  • Sustained decline in available host memory despite no growth in running container count.

Detection Strategies

  • Monitor /dev/shm inode counts and total size per IPC namespace using ipcs -m and df -h /dev/shm.
  • Correlate container restart events from the Podman event stream (podman events) with kernel OOM logs.
  • Alert on containers that share IPC namespaces and are configured with automatic restart policies.

Monitoring Recommendations

  • Ingest host-level memory and IPC metrics into a centralized observability pipeline for trend analysis.
  • Track container runtime audit logs for podman run invocations using --ipc=container: or --ipc=host.
  • Set thresholds for /dev/shm utilization and trigger alerts when consumption exceeds expected baselines.

How to Mitigate CVE-2024-3056

Immediate Actions Required

  • Apply the vendor-provided Podman updates from Red Hat, Fedora, and upstream distributions as listed in the Red Hat CVE-2024-3056 Advisory.
  • Audit running containers for shared IPC namespace configurations combined with automatic restart policies and stop untrusted workloads.
  • Restrict which users and workloads may create containers that share IPC namespaces on multi-tenant hosts.

Patch Information

Red Hat has published fixes and advisory guidance for affected Podman packages shipped with Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, and Red Hat OpenShift Container Platform 4. Fedora 40 users should update Podman through dnf. NetApp customers should review the NetApp Security Advisory NTAP-20241227-0002 for affected product guidance.

Workarounds

  • Avoid running untrusted containers with --ipc=container:<name>, --ipc=shareable, or --ipc=host.
  • Do not combine shared IPC namespaces with --restart=always for workloads originating from untrusted sources.
  • Constrain /dev/shm size per container using the --shm-size flag to bound per-container shared memory allocations.
  • Enforce memory limits at the cgroup level using --memory and --memory-swap to reduce per-container blast radius.
bash
# Configuration example: run containers with bounded shared memory and no automatic restart
podman run --rm \
  --shm-size=64m \
  --memory=512m \
  --restart=no \
  <image>

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.