Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @jschauma@mstdn.social
Cassandrich@dalias@hachyderm.io (2026-09-29 22:07:29)
@jschauma That isn't an option either. By accepting automatic/frequent updates, you are just adding more new vulns, and more of them are real vulns not fake ones like the stuff they're reporting.
The "1313 CVEs" are a lie. The hard problem is finding the 10-20 that are actually vulns and the 1-5 that are actually relevant to you amid the slopbros' DDoS attack on our attention. 🤬
The only solution is to close off all of the attack surface. Disable module loading entirely or switch to allow list model to block all of the "IPsec shit nobody asked for". Disable io_uring and other optional niche syscalls. Don't give out user accounts, and don't assume running network-facing junk daemons is safe just because they're running as nobody or chrooted. Etc.
---Reply---
Cassandrich@dalias@hachyderm.io (2026-09-29 22:14:41)
@jschauma As an example, I pulled out a random CVE number from the giant list and looked at it:
https://www.cve.org/CVERecord?id=CVE-2026-97990
There is nothing in the report to indicate anything resembling a vulnerability. Maybe it is, but the report is just a normal bug fix for incorrect interpretation of an error return value.
It may be that this leads to OOB accesses later, but that is not established. Nonetheless, a CVE was assigned. 🤬
Reply
---Replies---
Jan Schaumann@jschauma@mstdn.social (2026-09-29 22:18:16)
@dalias Yep. It's the kernel team's decision to assign a CVE ID to just about any change. Combined with the onslaught of AI findings, this gets us to thousands of CVEs, and trying to assess which, if any, are meaningful and affect your particular stack and configuration is, IMO, no longer possible.