CVE-2026-68151

What it actually does

This is a local denial-of-service flaw in the Linux kernel FDPIC ELF binary loader. When processing a crafted FDPIC ELF executable containing more than one PT_INTERP program header, the loader incorrectly honors later interpreter entries instead of stopping at the first one. Each repeated interpreter handling path can leak the previous interpreter name allocation and interpreter file reference, including a write-denial reference taken by open_exec(). Because that denial is not released, the referenced interpreter file can remain unwritable until reboot, and repeated execution can consume kernel resources. The issue is reachable by an unprivileged local user able to place and execute a crafted binary on an affected kernel configuration.

Why it matters to the business

On affected Linux systems, a low-privileged local user or process could degrade availability by making selected interpreter files temporarily unwritable and by leaking kernel resources through repeated execution of crafted binaries. The practical impact is most relevant to systems using FDPIC ELF support, often embedded or specialized Linux deployments, where a local foothold can be turned into operational disruption. There is no current indication of public exploit maturity, known ransomware use, or CISA KEV listing, but the bug is newly published and should be remediated through normal kernel patch cycles, with higher priority for multi-user, build, appliance, or embedded environments that execute untrusted local code.

How an attack unfolds

An attacker first needs local code execution, such as shell access, the ability to run workloads, or the ability to upload and execute a binary. They create an FDPIC ELF executable with multiple PT_INTERP program headers. When the vulnerable kernel's binfmt_elf_fdpic loader scans the program headers, it processes more than one interpreter entry. Each subsequent PT_INTERP can overwrite internal interpreter tracking while leaving the previous allocation, file reference, and write-denial state unreleased. The attacker repeatedly runs the crafted executable to accumulate leaked references and to keep targeted interpreter files in a state where writes fail, typically until the host is rebooted or the patched kernel is used. The attack does not require elevated privileges, but it does require an affected kernel path and the ability to execute the crafted file.

How to fix it

Apply a Linux kernel update that includes the fix to binfmt_elf_fdpic so only the first PT_INTERP header is honored. Because no package-specific fixed versions were provided, use the fixed kernel versions or vendor advisories from the relevant Linux distribution, appliance vendor, embedded platform vendor, or upstream stable kernel branch. Reboot into the patched kernel after installation; live patching should only be considered sufficient if the vendor explicitly covers this code path. Where immediate patching is not possible, reduce exposure by preventing untrusted local users or workloads from writing and executing arbitrary binaries, mounting writable untrusted locations with noexec where operationally feasible, restricting shell/container access, and disabling or removing FDPIC ELF support only if the platform does not require it and the vendor supports doing so. A reboot may clear existing leaked write-denial state, but reboot alone does not fix the vulnerability.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel version is older than the vendor-fixed build and whether the kernel configuration or platform includes FDPIC ELF binary support. Validate remediation by verifying the system has booted into the patched kernel, not merely installed it. Functional validation can include attempting a controlled execution test with a benign crafted multi-PT_INTERP FDPIC ELF sample in a lab environment and confirming the vulnerable behavior no longer occurs. Operationally, confirm that previously affected interpreter or executable files can be modified or replaced after rebooting into the fixed kernel. Also review package-manager and kernel inventory data to ensure all affected fleets, images, appliances, and embedded builds have received the corrected kernel.

Typical attack path

1. Gain local ability to write and execute files on an affected Linux system.
2. Generate or upload a crafted FDPIC ELF binary containing more than one PT_INTERP program header.
3. Execute the crafted binary so the vulnerable binfmt_elf_fdpic loader processes multiple interpreter entries.
4. Cause leaked interpreter references and unreleased write-denial state in the kernel.
5. Repeat execution to increase resource leakage or keep selected interpreter files unwritable.
6. Trigger operational impact such as failed updates, failed file replacement, or local denial of service until remediation or reboot.

How to detect it

This vulnerability is unlikely to produce a unique kernel log entry by default, so detection should focus on local execution telemetry and symptoms. Review auditd, eBPF/EDR process telemetry, shell history, file integrity logs, package-manager logs, and system logs for repeated execution of newly created or unusual ELF files from writable paths such as /tmp, /var/tmp, /dev/shm, user home directories, upload directories, CI workspaces, or container writable layers. Look for failures to update, replace, or overwrite interpreter/executable files with errors such as 'Text file busy' or ETXTBSY after suspicious local binary execution. If a suspicious binary is found, inspect its ELF program headers with readelf or equivalent tooling and look for multiple PT_INTERP entries, which is abnormal and directly aligns with the exploit condition. On systems with process accounting enabled, correlate bursts of short-lived executions of the same unknown binary with later file replacement failures. Threat actor exploitation has not been reported in the provided data, so detection should be behavior- and artifact-driven rather than actor-specific.

• multiple PT_INTERP
• PT_INTERP
• Text file busy
• ETXTBSY
• binfmt_elf_fdpic
• /tmp/
• /var/tmp/
• /dev/shm/
• readelf -l

What your security team should do

• Prioritize patching systems that allow local users, CI jobs, containers, plugins, or uploaded workloads to execute arbitrary binaries.
• Identify Linux images and appliances with FDPIC ELF support and track them separately from standard server kernels, because exposure is configuration and architecture dependent.
• Reboot after kernel update and verify the active running kernel is the fixed version.
• Use noexec mounts and least-privilege execution controls on writable directories that receive untrusted files.
• Monitor for repeated execution of unusual ELF binaries from temporary, user-writable, upload, or build directories.
• Investigate reports of persistent 'Text file busy' or ETXTBSY failures when replacing interpreter or executable files, especially after suspicious local binary execution.
• If exploitation is suspected, preserve the crafted binary, audit logs, shell history, process accounting data, and kernel/package-manager logs, then reboot into a patched kernel to clear leaked state.
• Do not treat reboot as remediation; it only clears transient impact and must be paired with a fixed kernel.