CVE-2015-2925

What it actually does

The prepend_path function in fs/dcache.c fails to correctly handle directory renames performed inside a bind mount, enabling a local process to escape an intended chroot-style container boundary via a double-chroot sequence.

Why it matters to the business

A compromised or malicious process inside a container can reach the host filesystem and other containers, increasing the chance of full host takeover, data theft, or lateral movement in environments that rely on kernel namespaces and bind mounts for isolation.

How an attack unfolds

An attacker who already has a shell inside a container performs a rename of a directory that is part of a bind mount, triggering the flawed prepend_path logic and establishing a new root view that reaches the host; the attack has been known since 2015 but remains relevant on unpatched kernels still running older container runtimes.

How to fix it

Upgrade the Linux kernel to version 4.2.4 or later on all affected distributions; where immediate patching is not possible, restrict untrusted code from performing directory renames inside bind mounts and consider seccomp or LSM policies that block the renameat family of syscalls for container workloads.

How to confirm the fix worked

Run 'uname -r' and confirm the running kernel is 4.2.4 or newer; additionally, verify that container runtime configuration no longer permits the vulnerable bind-mount rename pattern by testing with a minimal reproducer that attempts the escape.

Typical attack path

1. Obtain local execution inside a container (via application flaw, misconfiguration, or insider access)
2. Identify a bind-mounted directory visible inside the container
3. Issue a rename syscall on a carefully chosen path to trigger the double-chroot condition
4. Verify escape by accessing host paths outside the original container root
5. Escalate privileges or pivot to other containers on the same host

How to detect it

Examine auditd or eBPF logs for sequences of rename/renameat syscalls issued against bind-mounted directories from within container cgroups; correlate with unexpected host-path accesses or chroot changes originating from container PIDs.

What your security team should do

• Prioritize kernel upgrades on any system still running kernels older than 4.2.4 that host containers
• Audit container images and orchestration manifests for bind-mount usage that could be abused
• Enable kernel-level protections such as seccomp-bpf profiles that deny renameat2/renameat for unprivileged containers
• Monitor EPSS and exploit availability; although currently low, any public PoC would raise urgency