Interestingly, Ubuntu Priority is set to "High" and not "Critical" which is defined as:
"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."
The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.
Interestingly, Ubuntu Priority is set to "High" and not "Critical" which is defined as:
"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."
Makes you wonder what the critical level is for
Remote RCE/data theft basically, as opposed to the local of High: https://ubuntu.com/security/cves/about#priority
1 reply →
> https://ubuntu.com/security/CVE-2026-98432
The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.
so just block multipath and add the firewall rule from article that drops packets with IPv4 options
Both of which we are finding out are apparently insufficient to mitigate this.
"the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection."
Is iptables considered an "application" here? I.e. can this bug be triggered before iptables drops the packet?
Put OpenBSD in front to protect that little scared penguin.
Hoping fix will be out soon so we don’t have to.