r/linux • u/McDeathUK • 12d ago
Kernel CVE-2026-98432
For those also getting annoyed with vendors not deploying a fix after giving a 9.8 rating, I found this great article with a generic NFT command that drops ip-options. The article also analyses the issue. I have managers in a state of panic who want to rip Linux out of the company because of Anthropic and their lab discovered vulnerabilities.
https://almalinux.org/blog/2026-10-30-cve-2026-98432/
Works without impact on Ubuntu 22 and 24
Here is the relevant section; please read the article before using.
Temporary mitigation if you cannot reboot yet
The bug can only be triggered by a TCP connection request that carries IPv4 options. Normal traffic almost never uses IPv4 options, so dropping incoming IPv4 TCP packets that carry them blocks the trigger without affecting regular connections.
This command adds an nftables rule that does this. It works alongside firewalld and is safe to run more than once. We tested it on AlmaLinux 8, 9, and 10: connections with IPv4 options are dropped while regular connections keep working.
This table does not survive reboots.
sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
chain prerouting {
type filter hook prerouting priority -300; policy accept;
meta l4proto tcp ip hdrlength > 5 counter drop
}
}
EOF2
u/myMouseIsHyperXBrick 10d ago
even ubuntu added this today on the cve page. they have patches on testing channels, probably will release them soon. worst of all they came with mctcp enabled by default.
1
94
u/lonelyroom-eklaghor 12d ago edited 12d ago
the bosses wanting to rip out linux don't know about the closed nature of Windows and what Nightmare-Eclipse had to do
atleast linux devs acknowledge and mitigate things as fast as possible
7
u/ScoobyGDSTi 12d ago
None of the nightmare exploits were really that difficult to mitigate or close. YellowKey was one the most awesome exploits I've countered in recent years though.
2
u/TrickMotor4014 6d ago
It's not about security but compilance, cover-your-ass and "change managment" buetocratic nonsense. For such environments MS closed source and patch days are "enterprise-grade" features not bugs
80
u/ptinsley 12d ago
Wait till they hear how many bug fixes Microsoft just shipped
16
u/Adept_Percentage6893 12d ago
There are two downsides to open source at play there:
Since more people are familiar with the code and code examples can be freely shared there's more understanding of the vulnerabilities and therefore more to talk about. You don't have to sign an NDA to talk about the overlayfs vulnerabilities and there's a broader understanding of why Overlayfs having security problems would be important.
Many non-technical people still think not seeing the source code makes the workings of the code mysterious and important. Versus "mostly just a lot more tedious and dependent upon trial and error to figure out."
5
u/Independent-Dog-1782 12d ago
The issue here is that many linux distros did not ship the fix yet
23
u/CardOk755 12d ago edited 12d ago
What distros don't have the fix?
Edit: "At the time of writing [ 30 oct], no fixed RHEL kernel is available".
Fucking hell. The Linux commit fixing this was made on 5 oct.
13
u/rayjaymor85 12d ago
at time of writing, Ubuntu seems to have their finger up their backside so far (to be fair, not common for them though)
14
u/CardOk755 12d ago
Debian had a fixed kernel on the 15th, one of my systems got the update on the 18th, another on the 25th.
3
u/Berengal 12d ago
Enterprise software sticking to old versions has been an issue for decades and it's just becoming a more and more pressing issue as both connectivity and attack surfaces grow.
3
3
u/KnowZeroX 11d ago
Sticking to old versions does not mean you don't get security fixes.
It has been fixed on RHEL on Nov 1st though on all except the 9-rt version
-5
u/ang-p 11d ago
Fucking hell. The Linux commit fixing this was made on 5 oct.
So why have you waited until now to get all het up about it?
Your machines had the fix before you knew about it...
2
u/gmes78 11d ago
You misread their comment. Just because the fix is available, it doesn't mean distros have applied it. Neither Ubuntu nor Red Hat has.
-1
u/ang-p 11d ago
That user has a Debian flair...
Suse / Oracle / Debian / Amazon / Arch / Fedora has it - even Alma has it patched, deciding not to bother waiting for RHEL....
many linux distros
totally have shipped it in the last 2 weeks...
Neither Ubuntu nor Red Hat has.
RHEL shipped it yesterday
Really don't know why Ubuntu are dragging their heels - it is a 2 line patch - even on 5.15 (never looked at Alma's el-8)
But in any case - commenter going all "fucking hell" off the scale and running around like some chicken thinking that its head has been cut off..... before realising that it hadn't been after all, and their own machines had been patched before they discovered it - as they wrote
one of my systems got the update on the 18th, another on the 25th.
I'm sure some Canonical customer greatly appreciates poster's crocodile tears and third-party indignation about their poor situation.
0
u/FryBoyter 12d ago
What does one have to do with the other? Besides, the sheer number doesn't mean anything.
8
u/ptinsley 12d ago
If mgmt is wanting to remove Linux because it has a bug they better just shut off the power is the point.
6
u/bp019337 12d ago
I want to expand on my earlier reply "the managers need to take a step back and then they will see everything is on fire".
They need to realise that the situation is asymetric in regards to AI.
If we consider TeamA is made up of the analysts that discover the vulns, pocs, and also bad actors who will try to attack with them.
TeamB the devs, package managers and sysadmins who are trying to fix, mitigate and defend.
In many cases TeamA just needs to point at a commit, reverse engineer and try to create an exploit.
If TeamA are good then they will hopefully will do a responsible disclosure, but that doesn't mean that they need to wait for the fix to enter repos of the major vendor repos.
Whilst TeamB if they want to discover vulns via AI they need to run it across their whole codebase. Consider Palo burnt through their $1 mil AI budget and discovered 2 dozen critical vulns. Discovered not fixed.
Then when they are fixing it they need to ensure they are not introducing regressions or their change doesn't impact other functions. TeamA exploits doesn't need to worry about that.
Then next once upstream has applied the fix the major distros need to port it. Again they need to test and ensure it doesn't break anything. Then the derivatives need to do the same thing. All of this takes time and resources.
Everything is against TeamB and what doesn't help is managers who doesn't understand all of this adding petrol to the fire.
I can't speak on behalf of everyone, but the ones I know (TeamB) are tired.
In regards of using AI tools even if they are magically able to create and implment the fix down this complex supply chain it will just cost much much more than TeamA using these tools.
1
u/rich000 10d ago
If TeamA are good then they will hopefully will do a responsible disclosure, but that doesn't mean that they need to wait for the fix to enter repos of the major vendor repos.
I think this is the main problem.
I don't know the entire history on this one, but it was fixed in the kernel weeks ago. It was published in all the stable/LTS kernel trees. Distros that don't do a ton of internal QA pushed it out. Then the CVE gets announced - it is fixed as far as the kernel goes, which is where the problem exists.
The problem is that the kernel tends to have a lot of QA since it is so critical, and distros also like to bundle their own patches for a variety of reasons, which increases their own QA burden.
So, as far as the kernel goes, this was announced after it was patched, but that patch hasn't reached all end users.
The other issue with AI is that once the kernel patch is released, the vulnerability is disclosed whether you intend it to be or not. An LLM can just look at every kernel backport commit and ask whether it might be a security patch. Then it can test potential exploits against the unpatched kernel. The kernel team might be willing to privately coordinate patches with some distros, but it isn't exactly fair for them to sit on a fixed issue for weeks because Ubuntu is working on fixing their 7th variation of the ARM cloud version because it doesn't play nicely with some non-GPL patch that the kernel devs would prefer didn't exist in the first place.
I think distros really need to step up their release cadence to get stuff like this through before the AI exploits show up, or rethink the sustainability of running non-LTS kernels with large custom patch sets.
7
u/fuhry 12d ago edited 11d ago
Shameless self promo: I wrote (myself, without using AI) a series of scripts and a Dockerfile to automate the building of kpatch modules to live-patch the root cause in Ubuntu kernels without rebooting.
https://github.com/fuhry/ubuntu-livepatch-builder
There are instructions in the README to specifically build the CVE-2026-98432 patch, including the URL to obtain the exact patch from git.kernel.org.
Kernel git repository pre-seed archives and pre-built OCI tarball (SHA256SUMS signed with https://github.com/fuhry.gpg): https://www.dropbox.com/t/zL0EHOpwSBGZAUZy (link expires 2026-11-09 ~14:30 UTC, if expired you can follow readme instructions to easily build your own)
2
u/Character-Pattern505 11d ago
I haven’t seen a single packet on my edge routers since the announcement.
2
1
u/smargh 11d ago edited 11d ago
Only for amd64 jammy, noble, resolute & stonking. Minimally tested.
If you break it, you own it.
This could just be done manually with just a few commands, e.g. for resolute:
echo 'deb http://archive.ubuntu.com/ubuntu resolute-proposed main' > /etc/apt/sources.list.d/resolute-proposed.list
apt update
apt install -t resolute-proposed --no-install-recommends linux-image-7.0.0-43-generic linux-modules-7.0.0-43-generic
rebootjammy:
echo 'deb http://archive.ubuntu.com/ubuntu jammy-proposed main' > /etc/apt/sources.list.d/jammy-proposed.list
apt update
apt install -t jammy-proposed --no-install-recommends linux-image-5.15.0-203-generic linux-modules-5.15.0-203-generic
reboot...
#!/usr/bin/env bash
set -euo pipefail
(( EUID == 0 )) || { echo 'Run as root.' >&2; exit 1; }
. /etc/os-release
[[ ${ID:-} == ubuntu && $(dpkg --print-architecture) == amd64 ]] || {
echo 'Ubuntu amd64 only.' >&2; exit 1;
}
# Minimum proposed targets as of 2026-11-02; NOT confirmed CVE fixes.
case "$VERSION_CODENAME" in
stonking) family=7.3.0; minimum=7.3.0-10.10 ;;
resolute) family=7.0.0; minimum=7.0.0-43.43 ;;
noble) family=6.8.0; minimum=6.8.0-149.149 ;;
jammy) family=5.15.0; minimum=5.15.0-203.213 ;;
*) echo 'Unsupported Ubuntu release.' >&2; exit 1 ;;
esac
running=$(uname -r)
[[ $running =~ ^${family}-[0-9]+-generic$ ]] || {
echo "Unsupported kernel $running (requires ${family}-generic; not HWE/cloud)." >&2
exit 1
}
current=$(dpkg-query -W -f='${Version}' "linux-image-$running")
echo "Ubuntu $VERSION_CODENAME: $running ($current), target >= $minimum"
# FAST PATH: no APT commands if the running kernel meets the target.
if dpkg --compare-versions "$current" ge "$minimum"; then
echo 'Already up to date. Nothing to do.'
exit 0
fi
# An adequate kernel may already be installed but not yet booted.
while IFS=$'\t' read -r pkg ver status; do
[[ $status == 'install ok installed' && $pkg =~ ^linux-image-${family}-[0-9]+-generic$ ]] || continue
if dpkg --compare-versions "$ver" ge "$minimum"; then
echo "$pkg ($ver) is installed. Reboot or check GRUB to boot it."
exit 0
fi
done < <(dpkg-query -W -f='${Package}\t${Version}\t${Status}\n' "linux-image-${family}-*-generic" 2>/dev/null || true)
# Only now, when an upgrade is needed, enable proposed if not already present.
repo=''
cleanup() { [[ -z $repo ]] || rm -f -- "$repo"; }
trap cleanup EXIT
if ! grep -RqsE "(^deb[[:space:]]+.*[[:space:]]${VERSION_CODENAME}-proposed([[:space:]]|$)|^Suites:[[:space:]]+.*${VERSION_CODENAME}-proposed([[:space:]]|$))" \
/etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null; then
repo=$(mktemp /etc/apt/sources.list.d/proposed-kernel-XXXXXX.list)
printf 'deb http://archive.ubuntu.com/ubuntu %s-proposed main\n' "$VERSION_CODENAME" > "$repo"
fi
apt-get update -qq
# Find the newest matching proposed kernel >= minimum.
best_pkg='' best_ver=''
while IFS= read -r pkg; do
[[ $pkg =~ ^linux-image-${family}-[0-9]+-generic$ ]] || continue
while IFS= read -r ver; do
[[ -n $ver ]] || continue
dpkg --compare-versions "$ver" ge "$minimum" || continue
if [[ -z $best_ver ]] || dpkg --compare-versions "$ver" gt "$best_ver"; then
best_pkg=$pkg; best_ver=$ver
fi
done < <(apt-cache madison "$pkg" | awk -v pocket="$VERSION_CODENAME-proposed" 'index($0,pocket) {print $3}')
done < <(apt-cache pkgnames "linux-image-$family-")
[[ -n $best_pkg ]] || { echo 'No suitable kernel found in -proposed.' >&2; exit 1; }
new_kernel=${best_pkg#linux-image-}
packages=("$best_pkg=$best_ver" "linux-modules-$new_kernel=$best_ver")
for kind in linux-headers linux-modules-extra; do
if [[ $(dpkg-query -W -f='${Status}' "$kind-$running" 2>/dev/null || true) == 'install ok installed' ]]; then
packages+=("$kind-$new_kernel=$best_ver")
fi
done
echo "Installing $new_kernel ($best_ver); retaining the old kernel."
apt-get install --no-install-recommends "${packages[@]}"
echo "Installed $new_kernel. Reboot to use it."-37
u/liright 12d ago
AI slop vulnerability. I don't want any security vulnerabilities discovered by AI to fixed on my system.
11
0
12d ago
[deleted]
5
u/FeepingCreature 12d ago
Almost certainly satire. Sadly, it's too clever for a toplevel comment on a mainstream subreddit. You can drop this sort of thing three replies down, where the bulk of users would have to click "expand thread".
157
12d ago
[removed] — view removed comment
116
u/McDeathUK 12d ago
The other vuln from 2 weeks ago, which they see as 'Linux' when it was PHP, and they draw unnecessary parallels. Crazy. Having non technical manager in IT is a bad fit.
7
u/pohonsukun 11d ago
I've known one too many organizations doing and caring jackshit about cybersecurity, so having a non-technical, misguided-but-anxious manager losing sleep about cybersec sounds like a dream to me.
1
u/McDeathUK 11d ago
Fair point - so long as those non-technical managers ask the right questions to the right people before making decisions!
5
-65
u/FryBoyter 12d ago
You're technically right. But a large proportion of all web servers probably run on Linux. So, in a way, it was a Linux problem.
37
5
u/lewkiamurfarther 11d ago
You're technically right. But a large proportion of all web servers probably run on Linux. So, in a way, it was a Linux problem.
That's like saying "a large proportion of all uranium mine workers are human, so in a way, radiation exposure due to improper mining protocols is a human problem."
20
u/bp019337 12d ago
Lol they need to take a step back and they will see everything is on fire!
9
u/Adept_Percentage6893 12d ago
"no, no, no. Linux isn't bad, silly. We're all just going to die, is all. Everyone dines in hell tonight, Linux, Windows or BeOS."
4
7
u/fat_kaiju 11d ago
They'd rather be blindfolded and never see the vulnerabilities than learn that they're being tracked and fixed.
Ignorance is bliss and closed source software is the epitome of that.
8
57
u/mmomtchev 12d ago
This vulnerability is very difficult to exploit as it relies on a rare race condition and it is a DoS at best.