Conversation

Notices

1. Embed this notice
   Michał "rysiek" Woźniak · 🇺🇦 (rysiek@mstdn.social)'s status on Wednesday, 22-Jul-2026 09:56:03 JST Michał "rysiek" Woźniak · 🇺🇦

   Linux kernel developers:

   We know what we're doing, we have loads of experience!

   Also Linux kernel developers:

   432 Linux Kernel CVEs in 24 hours:
   https://lore.kernel.org/linux-cve-announce/

   *sigh*

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 22-Jul-2026 09:56:02 JST Rich Felker

     in reply to

     @rysiek Is the 432 claim actually legitimate or is it slop vendor propaganda? What portion of them are a single issue split down into the smallest pieces possible to inflate the number of CVEs, hype up the "tools" behind them, waste responder time, and make defenders feel hopeless? What portion are even legitimate severity levels?

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 22-Jul-2026 09:58:54 JST Rich Felker

     in reply to

     @rysiek The issue isn't the language. The issue is the kernel's lack of any internal privilege boundaries. A memory safe language does not fix logic bugs in the implementation of memory/resource management. You fix this shit with an MMU not with language choice.

   • Embed this notice
     Michał "rysiek" Woźniak · 🇺🇦 (rysiek@mstdn.social)'s status on Wednesday, 22-Jul-2026 09:58:55 JST Michał "rysiek" Woźniak · 🇺🇦

     in reply to

     Look this is not about bashing Linux kernel developers specifically.

     The point I am trying to make is: we all make mistakes, that's just the human condition.

     But giving in to hubris, on the other hand, is a choice. And insisting that all is well and dandy and C is a "perfectly safe language as long as the developer knows what they're doing" is hubris.

   • Embed this notice
     Michał "rysiek" Woźniak · 🇺🇦 (rysiek@mstdn.social)'s status on Wednesday, 22-Jul-2026 09:58:56 JST Michał "rysiek" Woźniak · 🇺🇦

     in reply to

     I wonder ow many of those would have been prevented by using some kind of a modern compiled language that enforces at least some notion of memory safety. :thaenkin:

     But it's difficult to have linked lists in such a hypothetical language so that's a no go.

     Even though why would anyone use linked lists in this year of our kernel twenty twenty six?
     https://arxiv.org/html/2306.06942v2

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 22-Jul-2026 10:08:02 JST Rich Felker

     in reply to

     • Joshua Barretto

     @jsbarretto @rysiek That's why you don't use internal security boundaries. You use external ones enforced by the MMU, rather than putting the kernel and all the drivers together in one memory space that bypasses the MMU.

   • Embed this notice
     Joshua Barretto (jsbarretto@social.coop)'s status on Wednesday, 22-Jul-2026 10:08:03 JST Joshua Barretto

     in reply to

     • Rich Felker

     @dalias @rysiek Uh, what? The whole thing that makes memory unsafe languages so perilously dangerous for building secure systems is that UB can punch a hole right through whatever internal security boundary you might have designed. With a memory safe language you at least get the guarantee that the fallout of a bug can affect only the code/data that's explicitly connected to it at the level of the source code, allowing you to build up security boundaries.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 22-Jul-2026 10:15:25 JST Rich Felker

     in reply to

     • Joshua Barretto

     @jsbarretto @rysiek If the MMU isn't infallible, you have zero security boundaries anywhere. It's what you rely on to have any isolation between processes that are nominally isolated and not permitted to stomp over each other.

     Ring 0 drivers are a solvable problem in Linux. You can actually transplant them to a virtualized environment that offers the same formerly-internal APIs, without any rewrites or significant alterations. Not doing that is a choice.

   • Embed this notice
     Joshua Barretto (jsbarretto@social.coop)'s status on Wednesday, 22-Jul-2026 10:15:26 JST Joshua Barretto

     in reply to

     • Rich Felker

     @dalias @rysiek Oh, sure. I absolutely believe Tannenbaum was right and every year that ticks past is proving that. But I also think "we have to rely on the magic assumed infallibility of MMU hardware to build security boundaries" is just an utterly dismal cop-out when we also have the ability to build those boundaries in software too. We can have good things, actually.

     And in the case of Linux, which his already gone down the route of ring0 drivers, the problem absolutely *is* the language just as much as it is the lack of userland drivers.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 22-Jul-2026 10:26:46 JST Rich Felker

     in reply to

     @rysiek I really don't know what to make of that without taking a deep dive into the contents of the CVE assignments.

     Internally among the kernel folks, there is a faction that very much wants to accept slop, and inflating the number of CVEs serves a narrative that they "need AI tools" to deal with the volume. I don't have any evidence that this is what's going on, but I'd be stupid to disregard the possibility.

     The core problem right now is that we have a crisis of inability to trust large portions of the people we used to assume we could trust.

   • Embed this notice
     Michał "rysiek" Woźniak · 🇺🇦 (rysiek@mstdn.social)'s status on Wednesday, 22-Jul-2026 10:26:48 JST Michał "rysiek" Woźniak · 🇺🇦

     in reply to

     • Rich Felker

     @dalias I think you know I am one of the more critical of AI bullshit folks around.

     You might note that the link is to lore.kernel.org, not to some AI peddler press release.

     And if you click through, you will note these are all vulnerabilities with assigned CVE numbers, and these are all mentioned as resolved.

     In other words, at least it seems like kernel developers themselves thought these warranted actual CVEs and spent time actually fixing them.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 22-Jul-2026 10:31:22 JST Rich Felker

     in reply to

     • Joshua Barretto

     @rysiek @jsbarretto That sentiment I agree with entirely.

   • Embed this notice
     Michał "rysiek" Woźniak · 🇺🇦 (rysiek@mstdn.social)'s status on Wednesday, 22-Jul-2026 10:31:23 JST Michał "rysiek" Woźniak · 🇺🇦

     in reply to

     • Joshua Barretto
     • Rich Felker

     @dalias @jsbarretto

     > Ring 0 drivers are a solvable problem in Linux.
     > Not doing that is a choice.

     Yes, that's another kind of a choice that I think stems from hubris I mentioned.

   • Embed this notice
     Michał "rysiek" Woźniak · 🇺🇦 (rysiek@mstdn.social)'s status on Wednesday, 22-Jul-2026 13:42:41 JST Michał "rysiek" Woźniak · 🇺🇦

     in reply to

     • Rich Felker

     @dalias oh I am with you on that. But however you cut it – whether these are reasonable, serious CVEs that mark serious bugs; or, CVE diarrhea orchestrated to push for AI slop in kernel – this does not make Linux developers look like serious people.