Debian kernel updates - why so infrequent?

[oops]

... For example for the LTS kernel 6.1.0-20-amd64 from Debian, it is from the 6.1.85 linux.org ... so 20/85, the frequency is at 23.5%, almost 1/4 linux.org changes.

[davidy]

Updating a kernel and then actually pushing it out for all the world is actually 2 very different things. It takes man hours to vet it after writing it in the first place.

[DukeComposed]

... For example for the LTS kernel 6.1.0-20-amd64 from Debian, it is from the 6.1.85 linux.org ... so 20/85, the frequency is at 23.5%, almost 1/4 linux.org changes.

What's apples divided by oranges?

Debian kernel versioning is unique and separate from Linux mainline kernel versioning. You'll notice that you haven't seen a Debian 6.1.1 kernel, or 6.1.2, even though those kernels exist in linux.git. It's always 6.1.0-XX. The Debian kernel team maintains their own copy of the kernel source code, integrates upstream patches as they occur, compiles and publishes Debian-tailored updates carefully and systematically after they've performed regression testing, and after they've determined an update is both warranted and safe.

[pbear]

When I started using Linux, I would read change logs for kernel updates, mainly to get a sense of what zero day vulnerabilities might look like. Was a bit amused to discover how low the bar for what counts as a "security update" (e.g., someone with physical access might be able to stop a process). Meanwhile, when a serious vulnerability comes along (e.g., Boot Hole), updates happen very quickly.

[DukeComposed]

When I started using Linux, I would read change logs for kernel updates, mainly to get a sense of what zero day vulnerabilities might look like.

Meanwhile, when a serious vulnerability comes along (e.g., Boot Hole), updates happen very quickly.

The irony here in following the public changes is that serious security problems are not discussed on LKML, but on a secret, select mailing list. This is how the top Linux kernel maintainers, meaning Linus and his lieutenants, discuss serious vulnerabilities, outside of the public eye, to coordinate with researchers and vendors to introduce patches so that they can be pushed before the underlying flaw is announced.

[oops]

... For example for the LTS kernel 6.1.0-20-amd64 from Debian, it is from the 6.1.85 linux.org ... so 20/85, the frequency is at 23.5%, almost 1/4 linux.org changes.

What's apples divided by oranges?
...

It is mostly an approximation to summarize the problem, and to show the potential loss of time and energy. (to compile and install all these type of kernels)

[pbear]

... summarize the problem

What problem? I've never heard of a malware attack in the real world coming in through a Linux kernel vulnerability, not even a zero day never mind a patch in the works. Have you?

Anyhoo, if you don't like the Debian kernel update schedule, use something else. The schedule isn't going to change any time soon.

[CharlesV]

... summarize the problem

What problem? I've never heard of a malware attack in the real world coming in through a Linux kernel vulnerability, not even a zero day never mind a patch in the works. Have you?

There have definitely been exploited real world vulnerabilities on kernels. PwnKit and DIrty Pipe come immediately to mind. If you really want to know more, you can search here for linux or kernel and hunt them down.
https://www.cisa.gov/known-exploited-vu ... log?page=1

[oops]

... summarize the problem

What problem? ...

The stupid and potential loss of time and energy for almost nothing. (for only small and particular changes, to compile and install all these type of kernels too often)

[DukeComposed]

... summarize the problem

What problem? ...

The stupid and potential loss of time and energy for almost nothing. (for only small and particular changes, to compile and install all these type of kernels too often)

Sounds like what happens with a typical Arch install.