Back

@gregkh

Thx for the additional details (but FWIW, seems you missed that the toot already had mentioned that 26 were rejected whatever, easy to miss).

And thx for all your work, too!

@gregkh @kees @kernellogger I just reviewed the last month or so of fixes for drivers/gpu and how many you assigned CVEs for. and I think you're still substantially undercounting issues

there's a bunch of things that very much look like they can be used for denial of service stuff, and a bunch of tlb invalidation fixes and other races like that which ... well we learned how to exploit that stuff on the cpu very well, it's not that much harder for gpu. and more

but it's definitely a start

@gregkh @kees @kernellogger I wonder whether a script that sprinkles and later updates CVE annotations over a kernel repo (for a given git rev-list query, otherwise it'll take forever) would be useful for reviewing this all in a year

with that I could just fire up gitk and see which commits are tagged as CVE and which aren't, instead of having to manually compare ...

then a few randomized samples over the relevant subsystem history, and we should have pretty solid data

@ljs @kees @kernellogger @gregkh eh at least for drivers/gpu my take is that the only thing that works is if you backport the entire subsystem. and even that is very tricky to integrate into an older kernel without issues. otherwise you have schrödinger security because all it takes is someone to get bored enough to type the exploit

and given that rhel does that too I think @airlied is concurring

if the CVE flood is forcing more people towards that model, then I think that's a good thing.

@ljs @kees @kernellogger @gregkh @airlied like imo these bugs aren't "potentially exploitable", they are "I don't have the time to type the exploit and debug it to prove to you that it's exploitable"

and sure people can guess wrong, but from my very quick look for drivers/gpu fixes they're still guessing wrong with a very substantial false negative rate

@ljs @airlied @kees @kernellogger @gregkh well my take, from a quick look at least, is that for drm the current approach still undercounts the patches that I think are clearly exploitable.

there is a wide set of patches where it's hard to make the call without in-depth analysis, especially in the rather complex modeset paths. but a few fixes on the gem side are obvious exploit material on a pure design analysis basis

@ljs @airlied @kees @kernellogger @gregkh plus the kernel has no internal isolation, so even if it's not a full exploit on its own, a lot of the patches without cves I looked at are very useful tools to exploit otherwise harmless bugs elsewhere

@ljs @airlied @kees @kernellogger @gregkh a few stable kernels at most is the limit for backporting individual patches for drm. beyond that, it's just wishful thinking and yes, you're better off backprting the entire subsystem

imo for drm already lts kernels are an illusion

@gregkh @kees @kernellogger display port has a substantial sidechannel protocol, and hdmi gained that too with 2.0, and desktops tend to autoconfigure new screens so there's a lot of code that just runs automatically

so it's way beyond "EDID parsing bugs" at this point

@gregkh @kees @kernellogger I was more thinking to gather some data, then maybe discuss that next lpc and figure out what we need to do to catch them automatically

because trying to triage this manually is more than a full time job for something like drivers/gpu