A Linux kernel race condition present for roughly 14 years can be turned into root access by an unprivileged local user and, under affected configurations, used to escape a Docker container. The vulnerability, tracked as CVE-2025-39964, affects the AF_ALG interface that lets userspace programs request kernel cryptographic operations.

The risk is no longer theoretical. CISA has listed the flaw among vulnerabilities reported as exploited in the wild. Organizations running shared Linux servers, container platforms or systems where untrusted code can execute should therefore treat kernel updates and the required reboot as priority work.

A concurrency bug in cryptographic processing

AF_ALG accepts data for operations such as AES encryption and decryption through sockets. Internally, the kernel tracks submitted buffers with scatter-gather lists and uses a context flag to record whether unused space remains in the final page. Under normal sequential use, later data can safely be appended.

The vulnerable condition emerges when two threads write to the same operation socket. A lock protects much of the shared state, but the kernel can release it while one writer waits for buffer space. A second writer can then change the context before the first resumes. Carefully timed activity can leave the append flag enabled even though there is no valid final scatter-gather entry.

The next write may consequently reference metadata immediately before the intended array. Researchers showed that attacker-influenced heap contents could shape this invalid entry, building first a controlled data-copy capability and ultimately an arbitrary kernel write primitive. What begins as a race in a crypto socket can therefore become control over sensitive kernel memory.

From local access to root

The proof of concept used that write capability to change core_pattern, the kernel setting that determines how process crashes are handled. If this value begins with a pipe character, Linux launches a specified program as a core-dump handler. Replacing the setting and intentionally crashing a child process caused an attacker-controlled binary to execute with root privileges.

Containers do not carry their own kernels; they share the host kernel. A process that reaches this vulnerable interface and successfully exploits it can cross the isolation boundary in relevant Docker scenarios, turning access inside one container into control of the underlying host and potentially neighboring workloads.

STAR Labs researcher Muhammad Alifa Ramdhan found the issue during a 2025 Linux kernel audit for Google’s kernelCTF program, working with Bing-Jhong Billy Jheng to develop a reliable exploit. The submission reportedly earned a $113,337 reward. The affected code dated to Linux 2.6.38, released in 2011.

Patch, reboot and verify the running kernel

Upstream developers addressed the race by enforcing exclusive write ownership for AF_ALG contexts. A concurrent writer is rejected instead of being allowed to alter shared state while another operation is in progress. Fixed stable releases identified in public advisories include 5.10.246, 5.15.195, 6.1.155, 6.6.109, 6.12.50 and 6.16.10, although distribution vendors may backport the correction under different package versions.

Administrators should rely on their distribution’s advisory rather than comparing version numbers alone. A complete response should include:

• Install the vendor-provided fixed kernel package.
• Reboot hosts so they actually run the updated kernel.
• Confirm the active version after reboot, not merely the installed package.
• Prioritize multi-tenant hosts, CI runners, Kubernetes nodes and systems permitting local shell access.
• Review exposed workloads for unexplained privilege changes or modifications to core-dump settings.

Reducing untrusted local execution and hardening container workloads remain useful safeguards, but they do not replace the kernel fix. Because exploitation operates below the container boundary, patching the shared host is the decisive control.

Source: Cyber Security News.