* https://launchpad.net/ubuntu/+source/linux
You can pull them down with a "-t" added to your apt-get (but will not appear by default).
26LTS had the new kernel go to the updates/security repos on October 28.
* https://launchpad.net/ubuntu/+source/linux
You can pull them down with a "-t" added to your apt-get (but will not appear by default).
26LTS had the new kernel go to the updates/security repos on October 28.
How does that look like exactly?
Suites: resolute resolute-updates resolute-backports resolute-proposed
Then update:
sudo apt update -t resolute-proposed sudo apt install linux -t resolute-proposed
As for the way to add it, the full approach should be `add-apt-repository -yp proposed`, then `apt update`, then `apt install -t resolute-proposed linux-generic`
Chatgpt broadly agrees with me, for what it's worth: https://chatgpt.com/share/6ae9dfa3-10b0-83ec-abff-56149ab6d4...
Kubernetes node went to pieces. Apparmor prevented nginx from doing anything sensible, so the ingress didn't work. Easy fix when you know what's up, not so apparent when starting troubleshooting.
One app invoked tshark in a pod, apparmor denied it.
Those two were the visible ones. Apparmor now also blocks some unix signals that e.g. postgres uses in a few circumstances - leaving latent annoying bugs.
Pod shutdown hangs. Logs indicate 7 more apps affected by the signal "armor".
We're banning any new Ubuntu installs.
Not something you expect from a kernel patch upgrade
First, if this CVE did truly put every Ubuntu machine on the Internet at risk, we'd know about mass compromises by now, and there haven't been any reports. It means the CVE is not trivially exploited.
Second, the gravity of the CVE dictates the security release cycle. Emergency kernel patches carry risks of their own, and it would be worse to hurry a non-critical patch and crash a part of their massive user base.
Edit: I've been enjoying this comment going up and then into the negatives, what a roller coaster.
Customers and users expect alacrity for CVSS 9.8 CVEs in un-hardenable services like the TCP stack.
Whatever Canonical's security record or process has been for other CVEs does not excuse silence and delay in this case. Canonical, unfortunately, does not get to silently decide such a categorized CVE "is not trivially exploited" without criticism, and likely consequences.
iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP
Ubuntu managed to release the updated 26LTS kernel on October 28, but the other LTSes have been sitting around since 26 or 28, so I'm wondering why they haven't been moved to "security" or "updates" in the several days since.
Especially since their page on it mentions October 15
* https://ubuntu.com/security/CVE-2026-98432
and Debian released a couple of weeks ago.
The versions are mentioned in this page:
* https://ubuntu.com/security/CVE-2026-98432
I'm wondering if the CVE in question is not mentioned because it was embargoed so they did not want to accidentally leak things while the kernel went through the (public?) QA workflow. Perhaps the Changelog will be amended at some point to have the CVE?