CVE-2026-68151: Linux Kernel Privilege Escalation Flaw

CVE-2026-68151 Overview

CVE-2026-68151 is a Linux kernel vulnerability in the binfmt_elf_fdpic binary format handler. The flaw exists in the program header scan loop that processes PT_INTERP entries. A break statement inside a nested switch exits the switch but not the enclosing loop. When a binary carries more than one PT_INTERP header, the code overwrites both interpreter_name and interpreter, leaking the previous allocation and interpreter reference.

The leaked reference retains the write denial that open_exec() took on the file. That denial is never released, leaving the interpreter file unwritable for the lifetime of the system.

Critical Impact
An unprivileged local user can craft an ELF FDPIC binary with multiple PT_INTERP entries to leak kernel memory and permanently deny write access to arbitrary interpreter files. The condition can be triggered repeatedly.

Affected Products

Linux kernel binfmt_elf_fdpic binary format driver
Introduced in the pre-git history tree at Linux v2.6.11 by commit 91808d6ebe39 ("[PATCH] FRV: Add FDPIC ELF binary format driver")
Systems using FDPIC ELF binaries, typically no-MMU architectures such as FR-V, Blackfin, SuperH, and ARM/nommu

Discovery Timeline

2026-08-10 - CVE-2026-68151 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-68151

Vulnerability Analysis

The defect is a logic error in the ELF program header parsing loop within binfmt_elf_fdpic.c. The scan iterates over program headers and dispatches by type using a switch. The PT_INTERP case allocates memory for interpreter_name, calls open_exec() on the interpreter path, and stores the returned file reference. A break at the end of the case exits only the switch, so the loop continues processing remaining headers.

When the loop encounters a second PT_INTERP header, the case body runs again. It overwrites interpreter_name with a fresh allocation and replaces the interpreter file pointer without releasing the previous ones. The prior allocation is leaked. The prior file reference is leaked along with the write-lock that open_exec() acquired through deny_write_access(). Because allow_write_access() never runs for the orphaned reference, the interpreter file remains unwritable until reboot.

An unprivileged caller can trigger this by executing a crafted binary containing multiple PT_INTERP program headers. The behaviour differs from binfmt_elf, which stops after the first PT_INTERP. The fix aligns binfmt_elf_fdpic with that behaviour by breaking out of the loop after the first match.

Root Cause

The root cause is control-flow scoping: a break inside a switch nested in a for loop terminates the switch only. The code lacks a check for a previously seen PT_INTERP and lacks cleanup of prior interpreter state. The result is a resource leak combined with a persistent file-write denial [CWE-772].

Attack Vector

A local unprivileged user constructs an ELF FDPIC binary containing two or more PT_INTERP program headers pointing at chosen interpreter paths. Executing the binary causes the kernel to open each interpreter in turn, leaking references and holding write denials on every path except the last. Repeating the operation exhausts kernel memory over time and can lock out administrative writes to targeted files, including legitimate loader binaries. See the upstream fix at Kernel Git Commit 21eaf55 for the corrected loop control flow.

Detection Methods for CVE-2026-68151

Indicators of Compromise

ELF binaries whose program header table contains more than one entry with p_type == PT_INTERP, which is unusual and not produced by standard toolchains.
Interpreter files (for example, /lib/ld-uClibc.so.* or custom loaders) that unexpectedly return ETXTBSY on write attempts despite no visible process holding them open.
Sustained growth in kernel slab allocations tied to kmalloc sites in binfmt_elf_fdpic on affected architectures.

Detection Strategies

Statically scan executables in build and deployment pipelines for duplicate PT_INTERP entries using readelf -l or an equivalent parser.
Audit execve() calls on no-MMU systems where FDPIC binaries are expected, and flag processes that load unusual interpreter paths.
Monitor kernel memory accounting for anomalous growth patterns following user-driven execve() activity.

Monitoring Recommendations

Enable Linux audit rules on execve to record binary paths and calling UIDs on FDPIC-capable systems.
Track file lock and open-file table state to identify interpreter files stuck in write-denied state.
Correlate repeated execve failures or unusual ELF loads with the invoking user for further investigation.

How to Mitigate CVE-2026-68151

Immediate Actions Required

Apply the upstream Linux kernel patch that stops the program header scan at the first PT_INTERP, matching the behaviour of binfmt_elf.
Update to a stable kernel release that includes the fix from your distribution vendor.
Restrict execution of untrusted ELF FDPIC binaries on affected no-MMU systems until the patch is deployed.

Patch Information

The fix is available across stable kernel branches through the following commits: Kernel Git Commit 21eaf55, Kernel Git Commit 3349ef6, Kernel Git Commit 69ecc19, Kernel Git Commit 89b9121, and Kernel Git Commit e4563e0. The change ensures the loop terminates after the first PT_INTERP is honoured and prevents the leak of both the interpreter name allocation and the file reference.

Workarounds

Disable the binfmt_elf_fdpic handler in the kernel configuration (CONFIG_BINFMT_ELF_FDPIC=n) on systems that do not require FDPIC binary support.
Prevent unprivileged users from executing unreviewed binaries using mount options such as noexec on user-writable filesystems.
Use a mandatory access control policy (SELinux, AppArmor) to constrain which binaries untrusted users can execve().

bash

# Verify no unexpected duplicate PT_INTERP entries in deployed binaries
for f in $(find /usr/bin /usr/local/bin -type f -executable); do
  count=$(readelf -l "$f" 2>/dev/null | grep -c '^  INTERP')
  if [ "$count" -gt 1 ]; then
    echo "Suspicious multi-INTERP binary: $f ($count entries)"
  fi
done

# Confirm the running kernel includes the fix
uname -r