Re: 432 Linux kernel CVEs

[John Haxby <john.haxby () gmail com>]

> On 23 Jul 2026, at 11:00, Peter Gutmann <pgut001 () cs auckland ac nz> wrote:
>
> > If it is *vitally* important that your kernel *never* need to updated *ever*,
> > then a traditional kernel like Linux, *BSD, MacOS, iOS, or Windows is NOT
> > what you're looking for. What you need is a formally-proved kernel.
>
> That's the textbook answer.  The practical answer is "what you need is a
> minimal RTOS".  It doesn't need any formal proof, it just needs to be basic
> enough that there's nothing there to attack.  Not being able to get a shell on
> something because there isn't one is probably the single biggest win you can
> have in device security.


Live patching in it various guises is also useful.  I know at Oracle we had systems that were (and probably are) 
running for some years without a reboot and fully up yo date with security fixes.   The danger there, of course, that 
they've been hacked about while running and when, eventually, you do need to reboot it won't come up.  (When I worked 
at HP we had exactly that: two vital machines were both dependent on the other one being up and normally that's OK, but 
not when someone accidentally hit the big power button instead of the big exit button).

But to Peter's point, if there isn't a shell, the attack surface is greatly reduced.  I recall one customer who was 
adamant that they wanted to remove the shell to do just that.   I pointed out that, sure, there's no shell but they had 
python which is just as useful to an attacker and if the attacker really wants a shell then they could use python to 
download one ... 

There are, of course, numerous IoT devices and home routers and whatnot that are vulnerable to attack, shell or no 
shell, that are regularly recruited into botnets but in those the weakness is very rarely, if ever, the kernel -- it's 
badly written, unmaintained webapps or cgi programs.  I'm reminded that most of the security breaches that came to my 
attention over the years were in application code because updates were just too difficult, needing signficant effort 
and downtime.

In the end, it's not the number of CVEs, it's the design of the application platform.  The platform needs to have a 
seamless update mechanism *designed in*.   My phone and the laptop that I'm typing this message on both update 
automatically (or would do if I let them, [*]).  At least one of my linux machines used "dnf automatic" (as well as 
live patching) so I didn't need to worry if I want on holiday).  The point it, though, that those cheap home routers 
and IoT devices don't have automatic updates because the infrastructure needed to support that is too expensive: my 
ubiquity router and nest thermostats are relatively expensive because, in part, I paid for the infrastructure to update 
them.

And I don't care if you say you have a kernel with a formal proof -- you'll still have bugs in somewhere in the 
application stack.

jch



[*] I update my various devices first so that if there are any problems then I can warn my friends and family.   That's 
just paranoia now, I not had a problem with updates for, oh, 15 years or more.

Attachment: signature.asc
Description: Message signed with OpenPGP