I checked the kernel, not just the app

Words
616
Reading
3 min
9h
Listen to this post
~4 min

hive-cover-sysadmin-2026-11-02.png

Good afternoon everyone. I run Linux servers for clients. This week my check list changed. I did not start with the app. I started with the kernel under it.

Last week a Linux kernel flaw got a name. It is CVE-2026-98432. It sits in the IPv4 TCP code. That is the code that sets up a new TCP link. An attacker needs no login. No click. Only a TCP port that the server leaves open to the net. The flaw hits kernels from 4.4 and later. A fix went into the upstream stable kernels in mid October. But that is not the full story for most of us.

Here is the part that tripped me up at first. The upstream fixed numbers do not match what you see on a distro server. Ubuntu shows a number like 6.8.0 with more digits after it. Debian shows 6.1.0 with more digits. Red Hat shows 5.14.0 with more digits. Those numbers stay the same even after a backport fix lands. So you cannot compare your uname number with the upstream list and call it done. You have to check your own distro page for this CVE, and match the package version it names.

As of 1 November, the picture moved again. Debian had shipped fixed kernels. Debian 12 got 6.1.190-1, and Debian 13 got 6.12.113-1. Amazon Linux 2023 and Oracle Linux had shipped fixes too. Red Hat shipped a fix on 1 November for RHEL 8, 9 and 10. Ubuntu still had no fixed kernel on that date. Red Hat gave a stopgap on 30 October. It is an nftables rule that drops IPv4 TCP packets with IP options. That can cut the risk down. It is not the full fix. A fixed kernel is still needed.

Containers do not save you here. Every container on one host shares that host kernel. You can patch the image all day. The host kernel stays the same. On a Kubernetes cluster, that means the nodes need the fix, not just the pods.

So this is what I do now, in plain order. First, I run uname -r and I write down the distro and the full package version, not just the kernel number. Second, I open my distro tracker page for CVE-2026-98432 and I check if a fixed package is out for my release. Third, if a fixed package is out, I install it, I reboot, and I run uname -r again. Install without a reboot leaves the old kernel in memory. That step is easy to skip, and it costs you the whole fix.

Fourth, if no fixed package is out yet, I do the boring work. I close ports I do not need. I check that only the services I want sit on the net. I use a vendor filter only if my vendor gave one. And I check the vendor page again the next day. The status moved fast last week, and it can move again before Monday.

One more check I added. I look at which hosts face the net first. A test box behind a firewall and a live web server on the open net are not the same job. I fix the open ones first, then I work down the list.

This flaw is a good test of how a sysadmin works. The app can look fine. The site can load fast. And the layer under it can still be open. I like new tools, but this week the old job came first. Check the kernel. Check the vendor page. Then reboot and check again.

Which distro do you run on your main server, and has your vendor shipped a fix for this one yet?

Cover image: AI-generated

I checked the kernel, not just the app | Ecency