Patch CVE-2025-5278 in Coreutils

[Douglas R. Reno]

While reviewing my email earlier I found this:

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-                 [email protected]
         Oracle Solaris Engineering - https://blogs.oracle.com/solaris

(This is from oss-security)

The patch can be found at ​https://cgit.git.savannah.gnu.org/cgit/coreutils.git/commit/?id=8c9602e3a145e9596dc1a63c6ed67865814b6633

[Xi Ruoyao]

We need to pay attention that the i18n patch provides alternative code path for the code changed by the security fix, thus the i18n patch likely needs to be fixed as well.

[Xi Ruoyao]

Hmm, maybe I'm wrong. Fedora didn't change the i18n patch when they fix the security issue: ​https://src.fedoraproject.org/rpms/coreutils/c/e454479c5cd5c28ccbbc0e3dc5668c33ffd7a683?branch=rawhide

[Bruce Dubbs]

I was able to get the patch. I applied it and got:

patching file NEWS
Hunk #1 succeeded at 41 with fuzz 2 (offset 33 lines).
patching file src/sort.c
patching file tests/local.mk
patching file tests/sort/sort-field-limit.sh

That's OK. I then applied the i18n patch and got several offsets:

...
patching file src/sort.c
Hunk #11 succeeded at 1802 (offset 4 lines).
Hunk #12 succeeded at 1881 (offset 4 lines).
Hunk #13 succeeded at 1930 (offset 4 lines).
Hunk #14 succeeded at 1968 (offset 8 lines).
Hunk #15 succeeded at 2178 (offset 8 lines).
Hunk #16 succeeded at 2331 (offset 8 lines).
Hunk #17 succeeded at 2346 (offset 8 lines).
Hunk #18 succeeded at 2356 (offset 8 lines).
Hunk #19 succeeded at 2416 (offset 8 lines).
Hunk #20 succeeded at 2755 (offset 8 lines).
Hunk #21 succeeded at 2908 (offset 8 lines).
Hunk #22 succeeded at 2956 (offset 8 lines).
Hunk #23 succeeded at 2969 (offset 8 lines).
Hunk #24 succeeded at 2979 (offset 8 lines).
Hunk #25 succeeded at 3043 (offset 8 lines).
Hunk #26 succeeded at 3204 (offset 8 lines).
Hunk #27 succeeded at 3314 (offset 8 lines).
Hunk #28 succeeded at 3546 (offset 8 lines).
Hunk #29 succeeded at 4934 (offset 8 lines).
Hunk #30 succeeded at 5014 (offset 8 lines).
Hunk #31 succeeded at 5037 (offset 8 lines).
Hunk #32 succeeded at 5330 (offset 8 lines).
Hunk #33 succeeded at 5368 (offset 8 lines).
...
patching file tests/local.mk
Hunk #1 succeeded at 391 with fuzz 1 (offset 1 line).
Hunk #2 succeeded at 597 (offset 1 line).
Hunk #3 succeeded at 754 (offset 1 line).

The sort.c changes are at

@@ -1644,7 +1644,11 @@
@@ -1746,7 +1750,11 @@

The tests/local.mk changes add one line at line 391:

+  tests/sort/sort-field-limit.sh for the upstream fix
+  tests/misc/sort-mb-tests.sh    for the i18n patch
+  tests/i18n/sort.sh             for the i18n patch

So they do not conflict.

The patches only need to be applied in Chapter 8.

[Bruce Dubbs]

Fixed in trunk from the gcc15 branch.

[Douglas R. Reno]

SA-12.3-043 issued