Posts
290Following
87Followers
3124
repeated
lcamtuf 
lcamtuf@infosec.exchange
Computer folks, remember the precedence of operators! Consult this handy list if in doubt:
() [] -> .
! ~ ++ --
* / %
+ -
<< >>
< <= > >=
== != &=
=== &&& |||
?: ??= ( ^..^)ﾉ
(╯°□°)╯︵ ┻━┻
3
10
2
repeated
v6.5 fixed almost twice as many "high" CVEs (19) than the second most prolific release, v6.6 (11), with v6.4 & v5.17 tied for 3rd place (9). It seems like the rate of fixing is picking up.
Ignoring the first git release (v2.6.12), the "high" flaw introduction counts are relatively even. Highest (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 certainly more flaws are in all releases -- they just haven't been found yet.
0
2
1
repeated
Kees Cook 
kees@fosstodon.org
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.
1
8
3
Greg K-H
gregkh
0
3
7
Greg K-H
gregkhThe current scripts I wrote want a one-to-one mapping, but we will fix this in the future. Let's get the simple ones working first please. The mapping of commit to version numbers is complex enough to get right, we are still hashing it out as to the proper way to encode it all correctly.
See the huge comment block in the tool `bippy` for the issues involved in just single commit tracking: https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/bippy#n255
1
0
2
repeated
LWN.net
LWN@fosstodon.org[$] A turning point for CVE numbers https://lwn.net/Articles/961978/ #LWN
0
5
3
Anyway, I understand your basic point, but I think the way that other governments are starting to treat open source projects, this is something that everyone is going to have to deal with soon enough.
0
0
1
Greg K-H
gregkhAnd people shouldn't "fear" a CVE, it's just a hint of "hey, here's a bugfix that might pertain to you!" type of a signal. It's up to the receiver to determine if it does or not.
The main objection the kernel developers had previously about CVEs is that they were NOT an accurate signal at all, and were being totally abused by one company who used them to route around their broken internal engineering practices.
0
0
1
It really isn't much work to be a CNA, they have made the process very easy, highly recommended for any other open source project to do as well.
0
0
1
Greg K-H
gregkhSeriously, yes, software needs active maintenance, if you rely on it, help provide that maintenance where needed and possible. If no maintenance is possible, then look to use other software instead, or not at all (custom Makefiles are always fun!)
1
0
0
Greg K-H
gregkh
1
0
0
That's what we have done in the kernel for a very long time, and I predict this fascination of unique identifiers somehow meaning something is going to go away over time as it's obviously not sustainable for anyone involved.
Now if users of any type of software don't want to constantly update, then that is their fault, not the fault of the project itself. If the project doesn't provide stable updates, then no one should be using that software in the first place :)
1
2
2
4
5
11
Greg K-H
gregkhYes, if no one tells us that a specific issue/bugfix/whatever should have a CVE, and it doesn't get backported to stable (which will automatically trigger the review for CVE assignment), then you are correct, nothing will be assigned as obviously, no one noticed it.
So there is no sound :)
1
1
11
Greg K-H
gregkhThis has taken a long time, I'd like to thank all the groups that helped, and especially the CVE group themselves. Our application was a bit different than other groups, but they understood that this is important for security overall.
6
80
127