OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
1–10 of 26 posts
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#2I 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
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#3[deleted]
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#4I 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…
Wire the script to a pressure sensor in your seat, save-all/update/reboot every time you get out of your chair.
Bonus points for relaunching programs open during initial execution of script.
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#5I 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…
Wire the script to a pressure sensor in your seat, save-all/update/reboot every time you get out of your chair. Bonus points for relaunching programs open during initial execution of script.
perhaps we better add a job to automatically order new IoT devices from amazon too; once a month is probably good enough not to suffer. I think we just invented Upgrades-As-A-Service.. only $50/month for freshly not-yet-known-to-be-b0rked firmware!
are you gonna spot the LLM bill or should I?
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#6Theoretically they should slow down. I suspect people will be much pickier about which apps to use in production. Which, ironically, will be directly at odds with more and more products being pumped out..
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#7I 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…
Wire the script to a pressure sensor in your seat, save-all/update/reboot every time you get out of your chair. Bonus points for relaunching programs open during initial execution of script.
... or that the kernel can't be hot reloaded is itself a vulnerability?
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#8I 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…
There are pro/enterprise features that can upgrade the linux kernel without downtime, like livepatch or kpatch. (The non-proprietary klp-build is still missing tooling for most distros I think.)
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#9I 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…
Especially in environments where manglement mandate something like Qualys, leading to demands that systems must be patched to address the critical vulnerabilities that it's reported despite said vulnerabilities being unexploitable.
One that I trot out periodically as an example of this is a CVE that would only be exploitable if running on an IBM s390 with EBCDIC codepages. Our security team nevertheless wanted it patched, because Qualys said it was a vulnerability.
Re: OSS-SEC: 432 Linux kernel CVEs (in less than 32 hours)
#10I 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…
This is a confusing comment because Debian/Ubuntu/etc (you referenced apt) have separate security repositories that exist for this purpose. They have only security fixes and don't try to unnecessarily fix "other" stuff. I have not heard of the security repos pushing out a breaking update before.
`unattended-upgrade` uses only a subset of repos (ie security) and does this for you. If you actually wanted to schedule reboots, it can do that too.