GNU coreutils unexpand is vulnerable to a heap-based buffer overflow due to an integer overflow during buffer allocation when processing large tab stop (-t) values. The multiplication used to calculate the allocation size can wrap around, resulting in an undersized buffer. When processing crafted input, subsequent writes exceed the allocated memory, leading to an out‑of‑bounds heap write.
When running GNU coreutils unexpand with attacker-provided large tab stop (-t) arguments, this behavior leads to a crash and potentially achieve a heap write primitive depending on memory layout.
This issue has been fixed in the commit b60a159fdc5bfcf9988d3a4cb6f53abe8ad5d35d
GNU coreutils uniq is vulnerable to an out‑of‑bounds read due to incorrect handling of multibyte input when the -w (--check-chars) option is used. The findfield() function miscalculates the byte length of characters by repeatedly processing a fixed pointer instead of advancing through the input, resulting in an inflated length value. This incorrect length is later used in a memcmp operation, causing reads beyond the allocated buffer when processing crafted multibyte input.
On 5/29/25 02:46, Simon McVittie wrote: On Tue, 27 May 2025 at 14:43:44 -0700, Alan Coopersmith forwarded: The vulnerability is exploitable when:
1. A user passes the key specification in traditional format ( +0.18446744073709551615R)
An excellent question, but I don't know if the people who were involved in making the decision are on this list. (I wasn't, and was just passing on the information I'd found.)
https://www.cve.org/CVERecord?id=CVE-2025-5278 says that Red Hat was the CNA who issued the CVE - perhaps they have some insight?
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
On Tue, 27 May 2025 at 14:43:44 -0700, Alan Coopersmith forwarded: The vulnerability is exploitable when:
1. A user passes the key specification in traditional format ( +0.18446744073709551615R)
Thanks, smcv
A flaw was found in GNU Coreutils. The sort utility's begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data.
The vulnerability occurs in pointer arithmetic when parsing an unusually large key value (UINTMAXMAX) in traditional key syntax (+POS1.C1). If a user executes a crafted command like sort +0.18446744073709551615R, pointer arithmetic may wrap around and return a pointer before the start of the allocated buffer. This flaw can lead to an out-of-bounds memory read and potentially information disclosure.
Affected Versions: GNU Coreutils versions 7.2 through the current version are affected.
Integer overflow in the keycomparemb function in sort.c in sort in GNU Coreutils through 8.23 might allow attackers to cause a denial of service (application crash) or possibly have unspecified other impact via long strings.
The keycomparemb function in sort.c in sort in GNU Coreutils through 8.23 on 64-bit platforms performs a size calculation without considering the number of bytes occupied by multibyte characters, which allows attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly have unspecified other impact via long UTF-8 strings.
In GNU Coreutils through 8.29, chown-core.c in chown and chgrp does not prevent replacement of a plain file with a symlink during use of the POSIX "-R -L" options, which allows local users to modify the ownership of arbitrary files by leveraging a race condition.
chroot in GNU coreutils when used with --userspec allows local users to escape to the parent session via a crafted TIOCSTI ioctl call which pushes characters to the terminal's input buffer.
fts.c in coreutils 8.4 allows local users to delete arbitrary files.
The parsedatetime function in GNU coreutils allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted date string, as demonstrated by the "--date=TZ="123"345" @1" string to the touch or date command.
The "distcheck" Makefile rule in coreutils 5.2.1 through to 8.1 did use unsafe (predictable) temporary directory location for performing own tasks. This might allow local attacker to conduct symlink attacks under certain circumstances.
Upstream patch: --------------- http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=ae034822c535fa5
Credit: ------- Jim Meyering
CVE Request: ------------ http://www.openwall.com/lists/oss-security/2009/12/08/4
The "distcheck" Makefile rule in coreutils 5.2.1 through to 8.1 did use unsafe (predictable) temporary directory location for performing own tasks. This might allow local attacker to conduct symlink attacks under certain circumstances.
Upstream patch: --------------- http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=ae034822c535fa5
Credit: ------- Jim Meyering
CVE Request: ------------ http://www.openwall.com/lists/oss-security/2009/12/08/4
The default configuration of su in /etc/pam.d/su in GNU coreutils 5.2.1 allows local users to gain the privileges of a (1) locked or (2) expired account by entering the account name on the command line, related to improper use of the pamsucceedif.so module.
Race condition in Core Utilities (coreutils) 5.2.1, when (1) mkdir, (2) mknod, or (3) mkfifo is running with the -m switch, allows local users to modify permissions of other files.