upvote

points

by perarneng17 hours ago |
comments
upvoteby stouset16 hours ago|
[-]
There have been twelve CVEs reported against coreutils in the past twenty years.

There were forty-four against this project in just the last audit.

I am all for RIIR in cases where it makes sense. This does not even remotely appear to be one of them. By all appearances the quality of the code is extremely amateurish at best. coreutils has not been a significant source of vulnerabilities in the past, and they’re replacing it with code written by amateurs that performs worse and already has a worse security track record.

reply
upvoteby Ygg215 hours ago|
parent|
[-]
> There were forty-four against this project in just the last audit.

Was there an audit against coreutils? If not, it's not really apple-to-apple comparison.

reply
upvoteby stouset12 hours ago|
parent|
[-]
It doesn’t even matter. The sheer disparity in vulnerabilities over twenty years versus one year is impossible to hand-wave away.

We are talking about fourfold more CVEs over a twentyfold reduction in time.

reply
upvoteby gpm10 hours ago|
parent|
[-]
It really does matter. I don't know enough about this specific case, but multiple order of magnitude differences in CVE numbers are frequently explained by different policies towards finding and assigning CVEs in many many cases.

Absent more information the default should be to hand wave it away as probably such a difference. CVE counts are not a even slightly reliable metric.

reply
upvoteby collinfunk8 hours ago|
parent|
[-]
Most of them are TOCTOU races or improperly following symbolic links. For example, uutils mkfifo(1) would create a world-readable and writable FIFO before using chmod(2) to restrict its permissions. Another user could replace that file with a symbolic link between the mkfifo(3) call and the chmod(2) to change the permissions of arbitrary files [1].

Other ones I find concerning are that you could also bypass '-- no-preserve-root' with a symbolic link to root [2]. Or by using paths equivalent to "/", e.g., "/../" [3]. Historically, GNU coreutils has been pretty good with symbolic links and avoiding TOCTOU races. The only notable one I can remember is a chmod(1) bug [4].

I agree with your general point that the number of CVEs is a useless metric, though.

[1] https://nvd.nist.gov/vuln/detail/cve-2026-35352 [2] https://nvd.nist.gov/vuln/detail/cve-2026-35349 [3] https://nvd.nist.gov/vuln/detail/cve-2026-35338 [4] https://github.com/coreutils/coreutils/commit/425b8a2f534fe0...

reply