One of the controversial recent developments in the (Linux kernel) security world is that the Linux kernel developers have somewhat recently switched to a policy of aggressively issuing CVEs for kernel changes. It's simplest to quote straight from the official kernel.org documentation:

Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. [...]

Naturally this results in every new patch release of a stable kernel containing a bunch of CVE fixes, which has people upset. There are various things I have to say about this, but I'll start with the straightforward one: the kernel people are absolutely right about the difficulty of telling whether a kernel bug is also a security issue.

Modern exploit development technology has become terrifying capable, as has today's exploit developers. It's routine to chain multiple bugs together in complex ways to create an exploit, reliably achieving results that often seem like sorcery to an outsider like me (consider Google Project Zero's Analyzing a Modern In-the-wild Android Exploit or An analysis of an in-the-wild iOS Safari WebContent to GPU Process exploit). Modern exploit techniques have made entire classes of bugs previously considered relatively harmless into security bugs, like 'use after free' or 'double free' memory usage bugs; the assumption today is that any instance of one of those in the kernel can probably be weaponized as part of an exploit chain, even if no one has yet worked out how to do it for a specific instance.

Once upon a time, it was reasonably possible to immediately tell whether or not a bug had a security impact, and you could divide fixed kernel bugs into 'ordinary bug fixes' and 'fixes a security problem'. For many years now, that has not been the case; instead, the fact that a bugfix was also a security fix may only become clear years after it was made. Today, the line between the two is not so much narrow as invisible. Often the difference between 'a kernel bug' and 'a kernel bug that can be weaponized as part of an exploit chain' seems to be whether or not a highly skilled person (or team) has spent enough time and effort to come up with something sufficiently ingenious.

Are there bug fixes that are genuinely impossible to weaponize as part of a security exploit? Probably. But reliably identifying them has proven to be very challenging, or to put it another way the Linux kernel has tried to do it in the past and failed repeatedly, identifying bug fixes as non-security ones when they turned out to be bugs that could be weaponized.

(The Linux kernel still periodically has security bugs that are obvious once discovered and often straightforward to exploit, but these are relatively uncommon.)

(This expands a bit on something I said in a conversation on the Fediverse.)