Dirty Frag, and the Reboot I Skipped

Late one Monday evening I had an email sitting in my inbox from the company that runs the VPS this whole paper-trading setup lives on. The subject was "Important Notice," which has never once in my life meant anything pleasant.

The actual contents: a Linux kernel vulnerability called Dirty Frag, two CVEs (CVE-2026-43284 and CVE-2026-43500) chained together so any local unprivileged user can climb to root in basically one syscall. PoC was already public. Microsoft was already seeing the exploit used somewhere out in the wild. Severity 7.8 on the usual scale. For a box whose main contents are a handful of broker API keys, I'd rather not be the next person on that list.

My first instinct was to reboot into the new kernel and call it done. I keep -15 staged in /boot anyway, so the reboot itself would have been quick. About five minutes start to finish if everything came back cleanly.

The instinct turned out to be wrong, but it took me longer than I'd like to admit to notice.

What I actually did

Before anything else I pulled the changelog on -15: apt-get changelog linux-image-7.0.0-15-generic. The most recent entry was from April 22 and was a "packaging resync" — no mention of esp4, no mention of rxrpc, nothing about the IPsec path. Dirty Frag had been disclosed on May 7. So whichever kernel I had on disk, none of them carried the fix.

I also checked Ubuntu's CVE tracker for 26.04. Both CVEs were listed as "Needs evaluation," which is what they put up there when the kernel team has not yet decided when a patched build will ship. It can be days. It has been known to be weeks.

If I rebooted, the worst thing wouldn't have been the time. It would have been the trading daemons — XAUUSD, the oil pair, a handful of ETFs running together, the Form4 cron — all of which would have gone down for however many minutes the watchdog needed to wake them back up. Five to ten minutes of missed scanning windows in exchange for swapping one unpatched kernel for another unpatched kernel. I left the reboot alone for the moment.

Ubuntu's mitigation page turned out to be three lines, plus an update-initramfs call:

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

You put that in /etc/modprobe.d/dirty-frag.conf, run update-initramfs -u -k all so the boot path can't auto-load the modules either, and that's it. The exploit needs at least one of those three modules sitting in kernel memory to do its work. If modprobe's install command resolves to a program that exits 1, the module never gets there. The bug is still in the source code; the running system just has no way to reach it.

I ran lsmod first, mostly out of habit, and none of the three were loaded. I haven't used IPsec on this host since I set it up, and I'd be a little surprised if any of my Python code has incidentally opened an AF_RXRPC socket. That protocol mostly shows up in AFS filesystem clients, which I do not have running anywhere I can think of. So I didn't need rmmod. The trading daemons stayed up the whole time the change was going in.

After saving the conf and rebuilding the initramfs, I tested it the lazy way: sudo modprobe esp4. It came back with Error running install command '/bin/false' and exit 1. That's what's supposed to happen. I let the other two slide without testing, because by that point I had convinced myself the same answer would come back, and I had other things to do.

Letting cron handle the watching

The mitigation is a stopgap. Ubuntu will ship a patched 26.04 kernel eventually, and when that lands I want to drop the modprobe override and reboot exactly once, into the real fix. The odds I'd remember to manually type apt list --upgradable every Monday morning to check are realistically not great.

So I wrote a small shell script and put it in cron at 9 AM daily. It greps the upgradable list for linux-image and pings a Discord webhook if anything shows up. It also notices when /var/run/reboot-required is sitting on disk, though that one's a milder signal and I have it only complain on Mondays. If it nagged me every morning about the same flag, I'd start filtering the channel mentally and that's worse than no notification at all. There's a third check too, for whether /etc/modprobe.d/dirty-frag.conf is still on disk in case I delete it during some future cleanup pass and forget what it was for.

Anything that doesn't match those conditions, the script exits silently.

The first version of the script ran weekly. I left it like that overnight and looked at it again in the morning, and the obvious problem was that "weekly" means up to six days where a patched kernel could be sitting in the repository and I wouldn't have noticed. The box would still be safe — the modprobe override holds — but I'd rather not be leaning on a single trick for that long. So I bumped it to daily. The cron change took about a minute.

The reboot I'm not doing

/var/run/reboot-required was already set when I started this, by the way. -15 had been staged in /boot for some past apt upgrade to take effect. Rebooting now would change exactly one thing about my actual exposure to Dirty Frag, which is nothing, because -15 doesn't carry the patch either. The reboot would only be useful as housekeeping, and the cost of doing it is high enough that I'd rather do it once, on the right day, with a real fix on the other side.

When the patched kernel does land, I'll burn the daemon-restart cost in one go: drop the conf, run update-initramfs again, reboot into the fixed image. The procedure is sitting in the body of the Discord notification that the cron script will send when the time comes, so I don't actually need to remember any of it. The next thing I have to do about this is whatever happens after that ping shows up.

This is not investment advice. Past results don't guarantee future performance. All analysis reflects our internal research process only.