Posts
290
Following
87
Followers
3120
@schrotthaufen @pavel @kernellogger CVE assignment is ANYTHING but automatic. All changes are reviewed by 4 people in different ways and we vote/discuss them all, in public. Anyone is welcome to help us with this review, it's only about 34 changes a day to keep on top of.

Yes, once we agree "this commit should get a CVE" we have tools to make the assignment and publish the notice in an automated way, but all CNAs have something like that (if they don't they are wasting a lot of time doing it by hand.)
1
2
4
repeated

Thorsten Leemhuis (acct. 1/4)

I'd really like to read a well researched article that sums up how Linux distros reacted to the massive influx of CVE that started ~half a year – both for their packages and their live-patching offerings.

But I guess that is an enormous amount of work that no media outlet in this world is willing to pay anyone for writing. πŸ˜•

Slide taken from @gregkh's "Why are there so many kernel CVEs?" talk he gave at OSS China yesterday (https://social.kernel.org/objects/c9979d9f-399f-428b-ac56-c41598076dfa )

4
2
0
repeated

Don't panic! It's only 60 Linux CVE security bulletins a week https://zdnet.com/article/dont-panic-its-only-60-linux-cve-security-bulletins-a-week/ by @sjvn

Sure, it sounds like a lot, but it's just business as usual for .

1
2
0
@kurtseifried It's not like we weren't doing this before Febuary, we were, our rate of fixing hasn't changed at all from what I can tell.

Here's a good summary of the talk from @sjvn : https://www.zdnet.com/article/dont-panic-its-only-60-linux-cve-security-bulletins-a-week/
0
1
1
Here's a link to the slides for my "Why are there so many kernel CVEs?" talk I gave at OSS China yesterday:
https://kccncossaidevchn2024.sched.com/event/ed2b39a9a0cdfc1df18de67ce0c2f6be

Link to git repo for the slides if the schedule site acts odd for you:
https://git.sr.ht/~gregkh/presentation-security

It was fun, and will be the "set up" for my Kernel Recipes talk in Paris in a few weeks (only 3 conferences to go between now and then, travel is back in full swing.)
4
26
37
repeated

Ok, so the day has come. On the context of getting "/usr merge" on alpine, I am going to try update the FHS.

9 years after it was updated, big parts of it are out-of-sync with the current Linux distro conventions.

We (@postmarketOS) already pinged the @linuxfoundation about it in February, and their suggestion was to get somebody interested to do the work. So let's start that process now! Since the FHS mailing list seems defunc (I subscribed and sent an email in February that never got added to the archive), please send me an email at pabloyoyoista@postmarketos.org so we can get a list of people to start discussing the process

4
12
1
repeated

bert hubert πŸ‡ΊπŸ‡¦πŸ‡ͺπŸ‡ΊπŸ‡ΊπŸ‡¦

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/

15
22
1
repeated

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

1
2
1
repeated

"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

4
44
5
repeated

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

2
6
1
repeated
don't let anyone ruin your day

it's YOUR day!

ruin it yourself by attempting a gentoo install
0
8
3
@killyourfm If you ever need a guest, I'll be glad to do so, keep up the great work!
1
0
7
@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.
0
0
1
@ajd @kernellogger @mpe That implies that you actually have users of the driver. If so, why delete it?
2
0
1
repeated
Edited 10 months ago

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 βš” πŸ›‘ 🐧

2
11
1
@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 :)
1
6
18
@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.
1
0
1
@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
0
2
8
Show older