If you read commit logs of, say kernel.org and a distro kernel, and aren't concerned you are blissfully ignorant (and it is worse for the broader userland repos). It's particularly bad when they don't track a kernel.org LTS. Their kernel orgs are pretty lean and this has been the status quo for decades. CVEs of sufficient stature like this will get fixed but majority of other issues slip by unnoticed. LTS is kind of a myth, it trades ABI and API stability for a lot of other issues.
"Their kernel orgs are pretty lean"
For years, Red Hat employed more kernel developers than anyone and contributed more. These days they're "only" the fourth largest contributor, after Intel, Google, and Meta, but they are still among the largest corporate contributors.
If that's a lean kernel org, I don't know what a fat one would look like.
My hearsay, from friends and colleagues that work(ed) there, is that the shipped product is not really where you see these "heavy hitters".. a lot of the maintenance happens offshore.
Just makes sense that they would put the "heavy hitters" on feature development, not backporting security patches.
Unfortunately, as a ZFS on Linux user, LTS is the best way to get continual updates without breaking my system.
Probably best to not leave any ZFS system connected to the internet then.
Or perhaps this illustrates the value of running all web services under KVM rather than bare metal.
Over the past few months I've started to install newer ubuntu kernels using the mainline PPA. However, it goes long periods of time without getting updates, so it's not really a satisfactory solution. In one case I just built the kernel myself.
LTS doesn't work if you want immediate fixes like the current environment requires.