Recently, a Dutch hacker found a vulnerability allowing him to shut down 4 million solar power installations. A handful of mostly non-European places manage perhaps 100 GW of solar power in the EU. Any mishap there, or heaven forbid, a compromise, could easily shut down so much power that the European electricity grid would collapse. Shockingly, we regulate these massive control panels as if they are online birthday calendars. And that must change. https://berthub.eu/articles/posts/the-gigantic-unregulated-power-plants-in-the-cloud/

I think I finally found out why it feels like CISA live on Alpha Centauri.

> “It’s a myth,” she declared, “that software vulnerability is an inevitability. … It’s the same classes of defects we’ve known about for decades and known how to fix for years.”

This is both true and utterly wrong. It is true, we know how to detect and fix them for decades. In research.

But you know what we do not have? Industry tool that can be used in the industry based on this knowledge.

https://insideaipolicy.com/share/16704

"Linux would have prevented this!" literally true because my former colleague KP Singh wrote a kernel security module that lets EDR implementations load ebpf into the kernel to monitor and act on security hooks and Crowdstrike now uses that rather than requiring its own kernel module that would otherwise absolutely have allowed this to happen, so everyone please say thank you to him

It is time we realize and accept that there can never be a single nor objective criticality score for a CVE.

don't let anyone ruin your day

it's YOUR day!

ruin it yourself by attempting a gentoo install

@killyourfm I am, yes!

@killyourfm If you ever need a guest, I'll be glad to do so, keep up the great work!

@llvm @mpe @kernellogger @ajd That's not what staging is for (we tried it.) Just delete the driver and if someone shows up who uses it, revert the delete and all is good.

@ajd @kernellogger @mpe That implies that you actually have users of the driver. If so, why delete it?

I just wrote a blog post about how to use the new counted_by attribute in C and the Linux kernel. I've been mentioning this attribute in my presentations over the past year, and I thought it was about time to write about it. So, here you go:

"How to use the new counted_by attribute in C (and Linux)"
https://embeddedor.com/blog/2024/06/18/how-to-use-the-new-counted_by-attribute-in-c-and-linux/

I hope you find it useful. Thanks!

Kernel Self-Protection Project ⚔ 🛡 🐧

@bert_hubert Bert's talk is all the more important when you combine it with stuff like this: https://www.propublica.org/article/microsoft-solarwinds-golden-saml-data-breach-russian-hackers

RE: https://mastodon.nl/@bert_hubert/112608731406238492

@kernellogger @z3ntu Please note that the employer of the linux-next maintainer graciously allows them to do this work on company time because they value it. Perhaps other companies should also allow their developers to help out with this (note, at least one does, so Stephen isn't always alone here)

And we are allowed, and in some places, required, to go on vacation, so a few weeks off isn't going to really stall anything, we all have other ways of testing integrations, so don't worry :)

@pavel @Di4na @camdoncady @dangoodin @joshbressers @kurtseifried Pavel, the very next sentence in the text says "This leads to system crashes and other undefined behaviour."

{sigh}

You are now blocked.

@kurtseifried @anant @joshbressers @adamshostack @camdoncady @dangoodin Thank you for noticing, I spent a lot of time on making this information able to be created automatically as it is quite valuable for people to be able to EASILY, and programatically, determine if they should, or should not, even look at this specific entry. Everyone does actually know what small % of the 80,000+ files in the kernel they build into their image, and what versions they are running, right? If not, they have bigger issues than random CVE entries...

Side note, I create all the json from a set of wonderfully horrible bash scripts that parse the semi-free-flowing kernel git commit logs and branches to determine the information needed:
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/bippy
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/dyad
https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/id_found_in

@camdoncady @dangoodin @gregkh @kurtseifried @Di4na I cover that and many other things in this blog post

https://opensourcesecurity.io/2024/06/03/why-are-vulnerabilities-out-of-control-in-2024/

Over vorige post, je kan ook zeggen dat het kabinet "geen grip heeft op de migratie" (naar de cloud). https://berthub.eu/articles/posts/de-hele-overheid-naar-de-cloud-dat-is-een-politiek-besluit/

@ljs @joshbressers @lkundrak @mcepl @mort @vbabka What we are issuing meets the cve.org definition of "vulnerability" as defined by them.

Perhaps you are thinking the word means something different than it does in this context.

@lkundrak @mcepl @mort @joshbressers @ljs @vbabka What, you want people to slow down and NOT fix vulnerabilities? Or just not report them like we had been doing for the past decades?

All other operating systems are in the same boat, either they are not actually fixing things, or they are not reporting them. You ask them which it is...

@ljs @joshbressers @mcepl @mort @vbabka It's not a yes/no answer, that's not how the world works. One can hate the system but know that one must work within the system if one wishes to create change for the better. Much like we did for Linux adaption in the first place.

If you don't like CVEs, wonderful, just ignore them, they aren't causing you any issues. If you do like CVEs, great, I have loads of them for you :)

Again, the way CVEs for the Linux kernel were being allocated was broken and being abused by many corporations. We have now fixed that by hopefully making it work for _everyone_ who cares about CVEs, not just the few in the past that were taking advantage of it for their own gain. That is not "trolling", that is "working to fix the broken system that was previously in place".

@ljs @mcepl @mort @vbabka Yes, I said "trolling" many years ago in jest as there was no way for the kernel community to actually create CVEs like that, it was a joke.

But what I'm saying now is that I am NOT trolling anyone. The number of CVEs created for the kernel is exactly what cve.org wants us to do here as now we ARE allowed to be a CNA. And by being a CNA, we must follow the rules of cve.org which is what we are doing. I have had many meetings with the cve.org employees and board about this, and everyone seems to be in agreement that what we are doing now is correct and should be done this way.

Again, I'm not trolling anyone, and again, the kernel development model has not changed, all that has changed is that finally we are marking all potential vulnerability fixes as CVEs.

Again, if anyone knows of any CVE entries that we have assigned that should not be CVE entries, please let us know.