Incoming! A severe G4 Geomagnetic Storm is expected to arrive around 02:00 UTC Friday night / Saturday morning.
At least 5 Coronal Mass Ejections took place over the past 24 hours, directed towards Earth. These originated from a large and magnetically complex sunspot cluster (NOAA region 3664).
There is potential for disruption of communications, the electric power grid, navigation, radio and satellite operations.
@dentangle Convincing someone about some technical things is hard enough. Having them threaten, "I will use my position of power and influence to specifically ruin your attempts to be heard", though, is the troublesome bit. If I'm so wrong, present the evidence. Don't threaten to silence me. Sheesh.
@jens@smallcircles@dentangle You'd think so! But honestly this is a giant improvement. Only one threat and only one veiled ad hominem attack. There was no swearing nor direct insults. 🙄 So, yeah, it's better but still pretty off-putting for most people. I remain sad about all the developers we'll never see join the community.
@gregkh@kernellogger A 3% false positive rate seems entirely reasonable to me, especially given the volumes involved.
I still don't know what it'll do to my annually created CVE graphs, though. But I'm looking forward to having a whole year's worth of data to look back on. I think we're still at "early days" on this.
Is anyone using an i386 Linux kernel, built with Clang, and configured with UBSAN? :P Something is going very wrong with the UBSAN handler calls. Anyone wanna help me debug this? https://github.com/KSPP/linux/issues/350
@ljs@vbabka I think I found it: it looks like the handler calls aren't being emitted with knowledge of -mregparm=3 and are instead pushing arguments to the stack.
I've seen many Linux offensive security presentations and research include caveats like, "first turn off ASLR", or other stuff where the written exploit doesn't actually work with modern default systems. Here the excellent article includes details on enabling additional non-default defenses. 😍
Expect thousands of #Linux#kernel#CVE entries for issues already fixed in the past few years, as filing those according to Greg was a requirement to become a CNA:
@gregkh Is the Linux CVE json in a repo somewhere that people can send pull requests to? That might make it easier to get updates/contributions from folks doing further analysis of kernel flaws.
@vathpela@vegard@gregkh
The corollary of "security bugs are bugs" is "bugs are security bugs". Without an omniscient view of all Linux deployments and the associated reachability analysis, the objective security impact of a behavioral weakness cannot be assessed. And this is especially true given that (even minor) flaws are commonly chained together to build exploits.
This new process won't be perfect, but it'll be a whole lot closer to reality than the prior process: assigning no CVEs. :)
Last time I did a Linux kernel security flaw lifetime analysis was back in 2021. It showed the average time between flaw introduction and fix was 5.5 years for 108 "high priority" CVEs: https://outflux.net/slides/2021/lss/kspp.pdf
I refreshed my dataset today and was surprised to see that now with 103 more CVEs, it's still holding at 5.5 years. This actually means Linux is getting faster at finding issues, but the (diminishing) technical debt of the past is still dragging down the average.
v6.5 fixed almost twice as many "high" CVEs (19) than the second most prolific release, v6.6 (11), with v6.4 tied for 3rd place (9) with v5.17. It seems like the rate of fixing is picking up.
Ignoring the first git release (v2.6.12), the "high" flaw counts are relatively even. The most flawed (i.e. most well tested/researched) releases have been v3.8 (9), v3.18 & v2.6.20 tied (8), and v5.9 & v4.1 tied (6).
But there are certainly more flaws in all releases -- they just haven't been found yet.
"The most likely way for the world to be destroyed, most experts agree, is by accident. That’s where we come in; we’re computer professionals. We cause accidents."
-- Nathaniel Borenstein
