Perhaps that's the problem? Surely they use a version control system that allows them to branch off of older commit for these kinds of urgent patches.

So distros should release a new kernel for each CVE? Or only the "important" CVEs? And if two "important" ones come out two days apart there should be two kernels running through the QA pipeline? So that people can reboot their production systems two days apart?

Yes, if two 9.8 kernel CVEs come out two days apart, then yes, everyone should be rebooting their prod systems two days apart.

Timely security updates are important. Debian LTS had the patch within a couple days. It’s not like you have to update if you don’t want to.

No, just the ones rated 9 or higher

Yes.

> So that people can reboot their production systems two days apart?

A lot of people don't reboot their systems. They build new ones, shift workloads and traffic over, and decommission the old ones. I can do that multiple times a day if required with no disruption of services.

You don't have to stay patched if you judge the risk doesn't make it worth it, but Ubuntu is pretty much the only distro that made the choice for you.

> Or only the "important" CVEs?

This is why CVEs have severity ratings

> And if two "important" ones come out two days

Yes

> running through the QA pipeline

This is also why customers evaluate the CVE and their risk. The company I work for skipped a patch for a CVE because it was for areas that we don't use and weren't exposed to the public internet.

This isn't a "bug in the queue," it's a severe security update that requires immediate patching.

Pretty much every software vendor has a way to ship fixes for 0-day exploits. They're called "hot fixes" and generally bypass normal releases. (IE, where I work, we can bypass our normal releases and publish emergency bugfixes in a matter of hours.)

That's why the fix needs a leader to basically pull everyone into a room and say "get it out by EOD."