![]() |
|
Message-ID: <faad8379-ad8d-48fe-8de4-9cfea8046125@oracle.com> Date: Tue, 27 May 2025 14:43:44 -0700 From: Alan Coopersmith <alan.coopersmith@...cle.com> To: oss-security@...ts.openwall.com Subject: CVE-2025-5278: Heap Buffer Overflow in GNU Coreutils sort 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@...cle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.