CVE-2026-68187: exec: fix unsigned loop counter wrap in transfer_args_to_stack()

Published Aug 10, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

exec: fix unsigned loop counter wrap in transferargstostack()

The stop value is derived from bprm->p >> PAGESHIFT. The index variable is an unsigned long. If bprm->p drops below PAGESIZE and stop becomes zero the loop condition index >= stop is always true.

After the index == 0 iteration the decrement wraps to ULONGMAX and bprm->page[ULONGMAX] reads sizeof(void ) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmaplocalpage() and PAGESIZE 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 < PAGESIZE. On !MMU bprmsetstacklimit() and bprmhitstacklimit() are empty. So the only constraint on how far bprm->p is pushed down is validarglen(), i.e. that each individual string still fits in what is left.

bprm->p starts at PAGESIZE MAXARGPAGES - 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 : transferargstostack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] memcpy+0xd4/0xf8 [<800d5f6a>] loadflatbinary+0x43a/0x65e [<800a2de4>] bprmexecve+0x1d4/0x316 [<800a351a>] doexecveatcommon+0x12e/0x138 [<800a3d44>] riscvsysexecve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt

This is an arcane bug but we should still fix it.

Count down from MAXARGPAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop.

Only CONFIGMMU=n builds are affected, transferargstostack() is used by binfmtflat and binfmtelffdpic on nommu only.

The loop predates git history. commit 7e7ec6a93434 ("elffdpictransferargstostack(): make it generic") only moved it from binfmtelffdpic.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 Software

1 affected component
Linux Kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Patch 7e7ec6a93434
  2. Compensating control

    For systems built with `CONFIG_MMU=n` where `transfer_args_to_stack()` is used (e.g., binfmt_flat and binfmt_elf_fdpic on nommu), mitigate by limiting exec of affected flat/elf-fdpic binaries until the fix is applied (to reduce likelihood of triggering the panic via the argument/environment stack copy).

Event History

Aug 10, 2026
CVE Published
via MITRE·11:59 AM
Data Sourced
via MITRE·11:59 AM
Description
Data Sourced
via NVD·01:20 PM
Description
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-68187?

CVE-2026-68187 has a risk level of 50, indicating a moderate severity.

2

How do I fix CVE-2026-68187?

To fix CVE-2026-68187, update your Linux kernel to the latest patched version that addresses this vulnerability.

3

What impact does CVE-2026-68187 have on my system?

CVE-2026-68187 can potentially lead to unintended behavior in the loop counter, risking system stability or security.

4

Is CVE-2026-68187 present in older versions of the Linux kernel?

Yes, CVE-2026-68187 affects several older versions of the Linux kernel prior to the fix release.

5

Can CVE-2026-68187 be exploited remotely?

The details of CVE-2026-68187 suggest it may not be directly exploitable remotely but poses risks in certain circumstances.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203