https://lists.gnu.org/archive/html/bug-coreutils/2025-05/msg00036.html and
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78507 report:
I am reporting a heap buffer overflow vulnerability (CWE-122) I've
discovered in the GNU Coreutils sort utility. This issue affects the
traditional key specification syntax processing and leads to an
out-of-bounds read.
Vulnerability Details
The vulnerability occurs when the traditional key specification syntax (
+POS1[.C1][OPTS]) is used with UINTMAX_MAX as the character position value.
The begfield() function in src/sort.c performs unsafe pointer arithmetic
that leads to integer wraparound, resulting in a pointer that points one
byte before the start of an allocated heap buffer.
The vulnerability is exploitable when:
1. A user passes the key specification in traditional format (
+0.18446744073709551615R)
2. During command-line parsing in main(), this sets key->schar to
UINTMAX_MAX
3. In fillbuf(), the begfield() function is called to precompute key
positions
4. The underflow occurs during the line key pointer calculation
5. The function returns a pointer before the buffer start
6. This invalid pointer is later passed through the call chain:
- keycompare() function assigns the pointer to texta
- When using -R (random sort), it calls compare_random()
- compare_random() calls xstrxfrm() with the invalid pointer
- xstrxfrm() calls strxfrm() on the out-of-bounds address
- strxfrm() attempts to read the byte before the buffer, triggering
the overflow
See the bug report at the above URL's for far more detail.
A maintainer responded with:
Indeed. I introduced this in coreutils 7.2 (2009).
One can repro on Fedora for e.g. with:
_POSIX2_VERSION=200809 LC_ALL=C valgrind sort +0.18446744073709551615R
poc_input.txt
==984625== Memcheck, a memory error detector
==984625== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==984625== Command: sort +0.18446744073709551615R poc_input.txt
==984625==
==984625== Invalid read of size 1
Going back to the more verbose code from coreutils 7.1 avoids the issue.
and appears to have pushed a fix & test case in:
https://cgit.git.savannah.gnu.org/cgit/coreutils.git/commit/?id=8c9602e3a145e9596dc1a63c6ed67865814b6633
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
