Cloudanix VulnDB

CVE-2026-68187

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

On certain small embedded Linux systems a bug in starting programs with very long command lines can crash the whole device.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Unsigned long loop index in transfer_args_to_stack() wraps from 0 to ULONG_MAX when bprm->p < PAGE_SIZE on !MMU builds, causing out-of-bounds read from bprm->page[ULONG_MAX] followed by uncontrolled kmap_local_page() and memcpy into the new process stack; loop never terminates.

Why it matters to the business

Kernel panic or fatal exception during program execution on embedded nommu Linux devices, leading to denial of service and potential instability in constrained environments such as IoT or legacy flat binaries.

How an attack unfolds

Attacker supplies a single argument or environment string slightly larger than 31 pages to an ELF-FDPIC or flat binary on a nommu kernel; this drives bprm->p below PAGE_SIZE, making stop=0, so the countdown loop wraps, reads garbage pointers, and copies arbitrary kernel memory into the victim process stack, resulting in oops or panic.

How to fix it

Apply the upstream fix that counts down from MAX_ARG_PAGES so the loop terminates at stop==0; rebuild and deploy kernels for all nommu configurations; where feasible enable MMU or migrate to MMU-capable hardware.

How to confirm the fix worked

Confirm CONFIG_MMU is not set, compile test kernels containing the corrected loop, and verify execve of arguments near MAX_ARG_PAGES succeeds without oops or wrap; inspect fs/exec.c for the revised countdown logic.

Typical attack path

  1. Supply oversized argument or environment string to execve
  2. Trigger binfmt_flat or binfmt_elf_fdpic loader on CONFIG_MMU=n kernel
  3. Enter transfer_args_to_stack with stop derived as zero
  4. Unsigned decrement wraps index to ULONG_MAX
  5. OOB read and memcpy of PAGE_SIZE bytes into stack

How to detect it

Search kernel logs for oops or panic mentioning transfer_args_to_stack, load_flat_binary, __memcpy during execve, badaddr near 0xffffffffffffffff, or cause 0x5 on nommu builds; correlate with recent execve calls that used large argument vectors.

  • transfer_args_to_stack
  • load_flat_binary
  • bprm_execve
  • ffffffffffffff
  • load access fault
  • Kernel panic - not syncing: Fatal exception in interrupt

What your security team should do

  • Identify and patch all nommu Linux deployments first
  • Add kernel oops monitoring for exec-related paths
  • Test argument-length limits in application launchers on affected devices
  • Consider disabling flat binary support if unused

The record

In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 ("elf_fdpic_transfer_args_to_stack(): make it generic") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.

Affected packages

Ecosystem Package Introduced Fixed