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

[Simon McVittie <smcv () debian org>]

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)

How would an attacker trigger this? Is this only exploitable if the 
attacker has control over the sort key (equivalent of -k), *and* the key 
is passed in to sort(1) via the traditional +POS syntax rather than the 
POSIX -k option?

I ask because, if there's no reasonable scenario where this is 
attacker-triggerable, then this would not be a security vulnerability 
but instead just an ordinary bug (which of course is worth fixing, but 
doesn't have to come with the urgency and overhead of dealing with a 
security vulnerability). Assigning CVE numbers to ordinary bugs dilutes 
their value for tracking genuinely exploitable vulnerabilities.

I would normally have assumed that sort(1) is meant to be resistant to 
attacker-supplied input (stdin or the contents of the file(s) given on 
the command-line), but not intended to be given untrusted and 
potentially attacker-chosen options?

In particular, if an attacker can give sort(1) completely arbitrary 
command-line options, then that's already an obvious arbitrary file 
overwrite via the -o option - which I would consider to be sort(1) 
operating as designed (not a vulnerability, it's only doing what its 
documentation says it will do), and instead a vulnerability in whatever 
higher-level component is providing it with attacker-chosen command-line 
options.

Thanks,
    smcv