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.

[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