Dear GNU Coreutils Maintainers,

I believe I have discovered an out-of-bounds read vulnerability in `ls`
that leads to memory disclosure (CWE-125 / CWE-200).

**Vulnerability Summary**

A specific long sequence of command-line flags causes `ls` to read and
print memory outside its intended bounds. The output includes system paths,
memory addresses, and other data not belonging to the current directory.
The program does not crash and returns exit code 0, making the issue silent
and potentially undetected.

**Proof of Concept**

The following command reproduces the issue on affected systems:
ls -lsZXx1vUutSsRrQqpoNnmLkIiHhGgFfDdCcBbAa

text

**Observed Behavior**

- `ls` prints a large amount of data not corresponding to the current
directory
- Output includes memory addresses, build paths, and other seemingly random
data
- The program does not terminate with an error
- Exit code is 0 (success)
- Running the same command multiple times produces different output
- A directory with few files outputs an inflated total blocks count (e.g.,
288,208 blocks for an empty directory)

**Expected Behavior**

`ls` should either reject the invalid flag combination, ignore unrecognized
or redundant flags, or list only the actual directory contents within
reasonable bounds.

**Affected Version**

- GNU coreutils 9.10 (latest from Debian)
- Output of `ls --version`:
ls (GNU coreutils) 9.10
Packaged by Debian (9.10-1)
Copyright (C) 2026 Free Software Foundation, Inc.

text

**Environment**

- Linux distribution: Kali Linux 2026.1
- Architecture: x86_64

**Severity Assessment**

This is an information disclosure vulnerability. A local attacker could
potentially read out-of-bounds memory contents, which may include sensitive
information or aid in bypassing ASLR. No special privileges are required.

**Additional Notes**

- This appears to be a memory corruption issue in argument parsing, likely
within `getopt_long` or flag processing logic
- The same behavior does not occur with shorter or more standard flag
combinations
- I have not tested other coreutils binaries, but similar behavior may exist

Please let me know if you require additional details, strace output, or a
valgrind report.

Thank you for your work on coreutils.

Respectfully,

Kaizen - Muhammad Abdullah Khan
(Independent security researcher)

Reply via email to