Linux CVE assignment process

Thank you for your service. You're doing a lot of good work. I fully understand why the kernel needs a CNA, but I think it's a shame that it does.

The whole idea of a CVE seems mistargeted, IMO, when applied to the kernel. I'd argue that it only makes sense at a product or distro level. You partially sketched this out in the post. An issue in a USB scanner driver might be catastrophic for the kiosk at the hospital where they scan my driver's license when I visit someone, and it's not applicable to a router that doesn't even include that class of driver in the build.

It's still useful to have a naming registry for these issues, but it seems like a structured issue naming repository that could be referenced by people who sell, e.g. kiosk products and router products, would be both less work for kernel maintainers and more useful overall. Doubly so given the dysfunctional way CVE lists are used to club IT organizations into deploying updates.

Probably not something any individual knows, but do you have a rough idea of how many automated testing labs run on the stable kernel releases, compared to how many of them run on mainline or maintainer trees or linux-next?

As someone swinging my pickaxe in the driver mines, I only see test reports in response to me either submitting a series that touches a subsystem with testing, or the lkp test bot swinging by. When I do get around to setting up my automated hardware test lab (probably LAVA?), I'll try to make it also chew on stable kernels either way.

Definitely not just asking this because I hit some amdgpu bug on Monday so rebooted into LTS just to hit a different amdgpu bug.