If you tried to reach this site for a few hours today and got nothing, that was me. I took it offline on purpose, and I’d do it again. Here’s the what and the why.
What happened
Yesterday I noted a new critical Linux kernel bug — CVE-2026-98432 — so I stopped what I was doing and looked hard at it.
The short version: it’s a use-after-free in the kernel code that sets up new IPv4 TCP connections. A race condition during the handshake lets the kernel reach for memory it already freed. It’s rated CVSS 9.8 — about as bad as the number goes — and the reason it’s that bad is the combination: remote, no authentication, no user interaction. An attacker just has to send a specially crafted packet to a publicly reachable TCP port. (BleepingComputer has a good writeup of the remote-root angle.)
A web server is, definitionally, a publicly reachable TCP port. So that’s me.
And the kicker: it reaches all the way back to kernel 4.4, which shipped in early 2016. This isn’t some exotic new subsystem. It’s been sitting in the TCP setup path for the better part of a decade.
Why I pulled it instead of waiting
I run — ran — this on Ubuntu. When I went looking for a patched kernel this morning, Ubuntu didn’t have one yet. The fix exists upstream — it’s in the stable kernels (5.15.223, 6.1.190, 6.6.159, 6.12.113, and so on) — but “it’s fixed upstream” and “my distro shipped me a package I can apt upgrade into” are very different things.
So I had a choice. Sit on a known-exploitable, remotely-root-able box and hope nobody points a packet at a hobbyist’s blog before Canonical ships the update. Or take it down. I took it down. Immediately. Out of an abundance of caution, as the lawyers say.
This is a personal blog. Nobody’s payroll runs through here. The cost of being dark for a few hours is that a handful of people got a connection error and I owe them an apology (hi — sorry). The cost of leaving a 9.8 exposed because taking it down was inconvenient is a category of mistake I’m not willing to make, even on something this small. The blast radius being small is not a reason to be sloppy. It’s a reason to practice being not-sloppy where it’s cheap.
And yes, thank you to the readers who reached out to tell me I was down! I’m grateful that you read my work, and that you care enough to tell me I’m down!
Why I rebuilt on Amazon Linux
Here’s the part that’ll be a little spicy for the Ubuntu crowd, and I say it as someone who’s run Ubuntu for years and will again.
Amazon Linux already had the patched kernel. AWS shipped updated kernel packages for Amazon Linux 2 and Amazon Linux 2023 to resolve CVE-2026-98432 — update, reboot, done. As of today, Ubuntu hadn’t. (That may well change by the time you read this. These windows are hours-to-days, not weeks. But I’m making the call with the information I have in front of me, not the information I wish I had — another habit from the Navy.)
So rather than babysit an exposed Ubuntu box waiting for an update, I rebuilt on Amazon Linux where the fix was actually in my hands. On AWS, running their distro, this is exactly the case AWS’s whole patch pipeline is built to serve, and today it served it faster than the alternative. Credit where it’s due.
Is this me switching teams forever? No. It’s me noticing which vendor had a patched kernel in my hands this morning and going where the fix was. When the thing on fire is a remote-root kernel bug, “who shipped the fix first” is a completely legitimate tiebreaker. I’ll happily move things back or around later. Right now, patched-and-rebooted beats every other consideration.
And honestly? Rebuilding the whole thing from scratch was fast. The site’s a static Hugo build; the server is cattle, not a pet. Blow it away, stand up a patched box, redeploy, done. If there’s a quiet lesson hiding in here it’s that the reproducibility you build in boring times is exactly what lets you make the scary decision calmly. I didn’t have to agonize about pulling the plug because standing a new one back up was cheap.
Oh, and I needed a restructure to add some more services anyway so two birds with one stone. Got a few more things into the terraform configs.
What you should actually go do
Enough about me. If you run anything exposed on Linux:
- Check your kernel against CVE-2026-98432 right now. If you’re on anything from 4.4 onward and haven’t patched, assume you’re affected.
- Patch and reboot if your distro has shipped the fix. Amazon Linux has. Check yours — the status is moving by the hour.
- If your distro hasn’t shipped it yet, decide — deliberately, not by default — whether that box should be reachable from the internet in the meantime. For a lot of us the honest answer for a few hours is “no.”
- Reboot actually matters here. A kernel fix you installed but didn’t boot into is a fix you don’t have. (Don’t ask how many people will miss this.)
That’s it. Not complicated. Just the kind of thing that’s easy to put off until it’s a bad day instead of a mildly annoying one.
Conclusion
The site’s back, on a patched kernel, and I’m not sorry I pulled it — only sorry you couldn’t read anything while I did. Somebody else wrote the bug. The only part that was ever mine was the response, and the response I’m proud of is the boring one: saw a 9.8 with no patch for my distro, stopped steaming, rebuilt where the fix actually existed, came back clean.
Take the conservative action first. Escalate the bad news loud. Keep your infrastructure reproducible enough that doing the safe thing is cheap. None of that is about kernels — it’s just how you stay calm when the parameter goes out of spec. The submarine taught me that, and a Linux TCP bug reminded me today.
If you got bitten by this one too — or if you think pulling a hobby blog over a CVE is wild overkill — drop me a note on LinkedIn and tell me how you called it. I’d genuinely like to know.