Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)

seclists.org

Post reply on HN
Print view View original

21–26 of 26 posts

Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)

#21

Post by guenthert »

mDyJzDPmBdG wrote: post #18
snvzz wrote: post #12

LLMs gave that one last push: Linux is not sustainable. We need to start looking at seL4 as the base, instead.

Isn't biggest attack surface in drivers? I expect distros to split less popular kernel modules into many separate opt-in packages at cost of default hardware support, and kernel developers to purge everything without active development team. The good old "lets leave it in tree, someone might find it useful" was nice idea but that is the part that is definitely not sustainable.

> Isn't biggest attack surface in drivers?

That would be my guess too, the current batch however is all over the place: Bluetooth, file systems, etc. (the network layer ones are probably the most interesting ones). And the severity is mixed as well, some are 'just' vulnerabilities to potential DOS attacks.

> I expect distros to split less popular kernel modules into many separate opt-in packages

In the past questionable modules were blacklisted rather than removed.

Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)

#24

Post by fluidcruft »

refp wrote: post #2

I remember when you were actually able to keep up with CVEs and you could (at least somewhat) prioritize patches while disregarding those which felt irrelevant. But now.. are we simply supposed to use our f̶a̶v̶o̶r̶i̶t̶e̶ package manager and batch update our systems in a loop? while true; do apt-get update && apt-get upgrade -y; sleep 1d; done wait. erhm... and probably an automatic reboot/kernel reload every 48h; TH…

Is anyone at Debian paid to keep up with this spigot of CVEs?

Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)

#25

Post by snvzz »

mDyJzDPmBdG wrote: post #18
snvzz wrote: post #12

LLMs gave that one last push: Linux is not sustainable. We need to start looking at seL4 as the base, instead.

Isn't biggest attack surface in drivers? I expect distros to split less popular kernel modules into many separate opt-in packages at cost of default hardware support, and kernel developers to purge everything without active development team. The good old "lets leave it in tree, someone might find it useful" was nice idea but that is the part that is definitely not sustainable.

Drivers run in supervisor mode as part of Linux, unfortunately.
Post reply on HN