No vulnerability name, no website, concise description, neutral tone, precise list of affected distros (RHEL + derivatives and some EOL Fedoras) and even mention of <i>unaffected</i> distros (current Fedoras), plain admission that no attempt was made to exploit. What a breath of fresh air!<p>(I am only joking of course. As a recovering academic, I understand that researchers need recognition, and I have no right to throw stones -- glass houses and all. Also, this one is really like regreSSHion's little sibling. Still, easily finding the information I needed made me happy.)
Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?
This is why I've always disliked Debian and Red Hat.<p>1. I hate the fact they have the hubris to think they can be smarter than the upstream developers and patch old versions<p>2. I hate the fact they don't ship vanilla packages, but instead insist on patching things for features that nobody relies on anyway, __because they're not upstream__.<p>Maintainers should stick to downloading tarballs, building them and updating them promptly when a new version is out. If there's no LTS available, pay upstream and get an LTS, don't take a random version and patch it forever just to keep the same version numbers, it's nonsensical and it was only a matter of time before people tried to exploit it. Just look at the XZ backdoor for instance, which relied on RedHat and Debian deploying a patched libsystemd.
The risk you take when you use a distribution that modifies upstream. Debian has had similar issues in the past (maybe not CVEs, but certainly packager-created bugs).
Is this in any way related to CVE-2024-6387 "RegreSSHion" discussed last week?<p><a href="https://news.ycombinator.com/item?id=40843778">https://news.ycombinator.com/item?id=40843778</a><p>Edit: Ok it seems very closely related; I was just surprised no one had linked the previous discussion.