"d@nny disc@ mc²" <[email protected]> writes: >> That would make it possible to use LibFuzzer to try to >> catch stuff like this. I expiremented a bit with AFL++, which seems >> fine, but I suspect it is less efficient since it needs to execute a >> process for each case. > > I have to admit: I'm pretty shocked to hear *the* gnu coreutils has > never considered fuzzing before.
I don't think that this is a fair interpretation of my message. I know Pádraig has done fuzzing at various points and has documented third-party fuzzing on his page [1]. GNU coreutils is also used as an example in various research papers about finding bugs. See for example this one about KLEE [2]. I assume there are also some about fuzzing that I am not aware of, but would be happy to learn more about. > (I was also shocked to learn that ASan and Valgrind were not yet part of > coreutils testing.) As Pádraig mentioned this isn't true. We have CI that uses ASAN, and I personally use both. > By adding the test case, Ismael has done all the work for us. **This is > really above-and-beyond work, and worth calling out for its excellence!** I agree that his report was well written, and on top of that, they provided a well-written patch including a test. I am thankful for that. Apologies for not making that clear. >> Thankfully, it seems pretty harmless. > > I don't know who taught you this, but this is exactly the form of "damage > control" that I've seen maintainers fall into so many times before, > where they completely misunderstand the PR situation at hand after a > use-after-free is discovered in *your* code. > Your engineering judgement, *even if it's totally correct*, is what's in > question right now, > fairly or not--so I recommend avoiding this category of response entirely. > It's totally legitimate to just post an ack to the mailing list confirming > you're aware of it, > if it seems like something you *absolutely must* render a response on (which > is going to be pretty rare). > > Unfortunately, you then go on to reword the *incredibly* solid and concise > analysis Ismael provided, > and your explanation is just much worse than the reporter's. > *This makes you sound incredibly out of touch!* My comment about it being "pretty harmless" was not meant to insinuate that was not a serious bug that should not be fixed. It was simply a comment stating that I thought it had minimal, if any, security impact. Given that it was reported publicly I assume Ismail likely felt the same, but I cannot speak for them. >> The bad read is the here: > > If you don't have the time and motivation to render a high-quality walkthrough > (*especially* if the actual report is as incredibly high-quality as Ismael's > submission was), > then I would *strongly* recommend (if you *do* take the route of posting to > the mailing list in real time): > (a) **take Pádraig's approach** (expertly formatting the report contents to > confirm its validity, without making a statement on it yet), > (b) or just take the opportunity to *thank* the submitter of the report, > *especially if it's a really good one like this!* Pádraig had thanked them on the GitHub issue [3]. Just because I did not thank them there does not mean that I am not thankful. In partciular, I dislike commenting on GitHub issues or PRs unless there is a request or question for the other parties. This is because commenting sends each participant a notification. Depending on how active a user is on GitHub, these notifications can quickly become unmangeable. I don't want to make their lives harder by simply commenting a "thank you", even if I would otherwise like to. >> But I agree it is worth applying before you make the release. > > So this line was so out of order (implying e.g. Pádraig or everyone else was > blocking on your approval to do the release???), > that I had to check if I was forgetting your name from somewhere. It was responding to Pádraig, who said on the GitHub issue, "This seems focused enough to include in the imminent 9.12 release." My opinion is not at all a blocker for the release. Speaking personally, I appreciate second opinions, even as simple as "this patch looks good" from Pádraig and others who work on coreutils. I'd assume that others feel similarly. Decisions made with a consensus of multiple knowledgeable people tend to be ones that fare better, I reckon. > I'm glad you're investing in coreutils and free software, > but I think you probably don't realize that **this page on your site[^6] is > making the coreutils project look really unserious about security:** > > [...] > > I don't really know how to explain this, but if *IBM* is writing more serious > incident reports than you,[^7] > then you essentially have negative credibility and you absolutely need to > lurk more, and maybe change your username. > > [...] > > [^6]: https://www.collinfunk.com/gnu-coreutils-cves > [^7]: https://access.redhat.com/security/cve/cve-2026-56391 I had planned to better document the current CVEs filed for coreutils. Evidently, I did not get very far. Anything there is my personal opinion; otherwise, it would be placed on gnu.org/software/coreutils. I could add an exaggerated warning banner with fancy CSS stating that everything is my personal opinion, but I have optimism that anyone who reads that page will understand that without it. Unfortunetly, the CVE assignment process is deeply flawed and allows anyone to file a CVE regardless of whether or not a bug is a security issue. In fact, the bugs may be totally fabricated by the reporter. This was the case for 2 in GNU Bison in 2025, which were later removed [4]. It is probably best not to attribute malice to the CNAs. They are likely too swamped with reports to adequately verify them. However, a frustrating fact is that CNAs will not remove CVE reports unless the bug is totally fabricated or unless the reporter agrees that it isn't a security issue. Reporters often have incentives not to agree that it isn't a security issue, e.g., they work for a company focused on software security and having CVE credit is good for business. It seems fairly obvious to me that this isn't a security issue, for example, since no one allows users to specify arbitrary values to the -t option of 'unexpand': $ yes ' ' | tr -d '\n' | LC_ALL=en_US.UTF-8 unexpand -t $(expr $SIZE_MAX / 16 + 1) Segmentation fault (core dumped) yes ' ' | tr -d '\n' | unexpand -t $(expr $SIZE_MAX / 16 + 1) There are interesting, and real security issues, that I planned on explaining in more detail than shown in the CVE description. E.g., CVE-2009-4135, CVE-2015-1865, and maybe some others I am forgetting about. Again, these are just my personal opinions. I do not feel the need to associate them with a pseudonym. Should they affect others opinions on me, good or bad, that is okay with me. > ***Executing a build process*** is where coreutils is frequently > invoked, and reading heap memory can often be used in vulnerability > chains exploited by nation-state actors. People die from this sort of > thing. And sometimes it can even be used for container escapes!!1111!! I think insinuating that we are getting people killed is a slight exaggeration, to put it lightly. Thank you to the extent that your message was indented to be helpful, but I agree with Pádraig that the tone was off. Collin [1] https://www.pixelbeat.org/docs/coreutils-testing.html [2] https://llvm.org/pubs/2008-12-OSDI-KLEE.pdf [3] https://github.com/coreutils/coreutils/pull/352 [4] https://seclists.org/oss-sec/2025/q4/83
