It's understandable that almost every piece of kernel code could potentially be a bad actor thus it would be tough to identify if every fix has security implications or not.
Still there must be a middle ground around common exploitation methods.
With the current rate of change that the kernel community develops at, including the patches backported to the stable/longterm kernels, it's impossible to try to evaluate each and every patch for "is this something that could be exploited or not?"
Companies have tried, it was fun watching them, but they quickly gave up and declared it impossible and much safer to just take all stable patch updates instead.
I've also talked to MITRE about just applying for a CVE for ever stable kernel patch (20+ a day), and while they appreciated me not doing that, they agreed that the current model of CVEs just does not work at all for the Linux kernel and that what we are doing is fine.
See my Kernel Recipes talk last year for details about all of that if you are curious.
Still, i think we do have in hand a very characteristic issue that even without knowing the details, simply by searching commit messages for "crypto" "key" "buffer" etc it should alert somebody to give it a second and third look.
The only thing (far!) worse than no impact marking is incomplete impact marking. That's just giving people a way to cop out, and they WILL use it.
If there is a commit that refers to a "memory leak" why shouldn't be, at least superfluously, checked, identified and have distros informed? (e.g 2ca068be09bf8e285036603823696140026dcbe7)
If the crypto fix was assigned early as a vulnerability would have stayed unpatched for that long?
With no marking it is clear what it means: commits have not been audited to identify security-relevant ones.
With partial, incomplete marking, unmarked commits can be one of two things: commits that have not been looked at, and commits that have been looked at and are believed to contain no security relevant changes.
The majority of commits will be in the "not looked at" category. And there's enough people around to have a significant subset of them be lazy, ignorant, unskilled or stupid and take that as "contains no security relevant changes."
P.S.: also, patches are already marked. By being included in the LTS series. Because that means they were important enough to get a backport — though not necessarily due to security impact.
Yes only a part of patches would be marked as such. That, major or minor, part would simply mean that people won't have to reinvent the particular wheel, as happened in this case. People won't be missing critical _discovered_ changes, the vulnerability would be discussed, recognized in its totality (PoC, documentation etc) and proper patches will be offered. There have been cases where LTS backports were old revisions of bad patches.
I think that baking LTS kernels is unnecessarily closer to an artistic approach of doing things.
No. Unless an issue is tested against HEAD, reporting it is just noise.
Reporting a fixed issue is a faux pas one has to pay for: Listening to snarky comments from friends and co-workers, or in this case, because they should know better, a few kegs of beer for the next FOSS event...