Do you have a specific library in mind? I think it would have to be an ancient, unmaintained C library.

But I think most OSS code isn't like this -- even C code born long ago, if it's still in wide use, has been hardened by now. Examples: Linux kernel, GNU userland, PostgreSQL, Python.

> even C code born long ago, if it's still in wide use, has been hardened by now. Examples: Linux kernel

There have been two LPE vulnerability and exploits in the Linux kernel announced today. After the one announced just last week. I don't think as much of the C code born long ago has been as carefully hardened as you think.

(Copy Fail 2 and Dirty Frag today, and Copy Fail last week)

Sure, I didn't mean to say that these examples are guaranteed 100% safe -- just that I trust them to be enormously more safe than software that accomplishes the same task that was hand-written by either a human or an an LLM last week.

One. "Copy Fail 2" and "Dirty Frag" are the same thing.

And consideing the size of the kenel, I call this stupendously good.

You (anyone, not you personally) write that much code yourself and let's see how well you did in comparison.

But that's the attacker advantage. You can do things right a billion times and one mistake will still take you down.

Are you sure? I'd really like that to be true, I felt bad finishing up work on Friday evening having applied the Dirty Frag mitigation to all our instances, but knowing (thinking?) the Copy Fail 2 vulnerability was still exploitable.

Technically there are two things that need to be fixed in the kernel indeed (and one of them was fixed already), but they're both under the "Dirty Frag" umbrella and the proposed mitigation to not allow the affected modules to load applies to them both.