CVE-2025-5278: Heap Buffer Overflow in GNU Coreutils sort

[Alan Coopersmith <alan.coopersmith () oracle com>]

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.coopersmith () oracle com
         Oracle Solaris Engineering - https://blogs.oracle.com/solaris