Skip to content

The Update Conundrum

Minimalist vector illustration of a home lab server and a closed laptop on a desk in a dim room. A translucent floating update list shows one item highlighted in amber with a matching warning triangle icon above it.

I started my home lab in 2021. It began with some basic Home Assistant automations and, over the last few years, has spiralled into a proper stack of VMs and containers. I’m self-taught, which is a polite way of saying I’ve learned most of what I know by breaking things and then stubbornly refusing to go to bed until they’re fixed.

This morning, I found a hole in that logic.

A kernel bug, CVE-2026-31431, or “Copy Fail” hit the news. It’s a logic flaw that lets an unprivileged process flip bytes in memory to get root access. Since I run LXC and Docker, my containers share the host kernel. A breach in one container could, in theory, let an attacker walk right out of their sandbox and own the entire host.

I checked my system and saw the build date was from March. The fix landed in late April. I’d run my usual updates and rebooted recently, so I should have been safe.

I wasn’t. I was still running the old, exploitable code.

I’ve always approached updates with a simple mindset: run them, and if it works, carry on. I don’t bother with simulated dry runs or overly cautious checks because I have solid backups. If an update breaks the system, I just roll it back and deal with it when I have more time. In several years of tinkering, I think I’ve only had to actually use that fallback once.

The problem was that my “if it’s broken, roll it back” safety net only works if the update actually happens.

Because I was only running apt upgrade, the system was being overly polite. When a kernel update requires a change in dependencies, something Proxmox kernels do frequently, apt just quietly “keeps back” the package. It doesn’t fail, it doesn’t break the system, and it doesn’t trigger a rollback. It just waits for me to notice. Since I wasn’t looking at the list of upgradable packages, I was rebooting into a system that was exactly as vulnerable as it was before I started.

Correcting it didn’t take a massive maintenance window. I just ensured my latest backups were intact, glanced at the “kept back” list, and used apt full-upgrade to force the transition.

It’s been a bit of an eye-opener. I’m not going to start obsessing over every minor package change, but I’ve definitely changed my workflow. I’m now making a point of actually looking at what apt list --upgradable is telling me. If I see the kernel or Proxmox sitting in that “kept back” pile, I know it’s time to move past the standard upgrade.

I’m also making it a habit to run apt autoremove --purge once I’m happy the new kernel is stable. There’s no point in digital hoarding; it just clutters the boot partition and makes future updates messier.

Missing a nuance like this is the trade-off of being self-taught. You pick up habits that work perfectly until a specific set of circumstances—like a memory-resident kernel exploit—proves they don’t. I’d rather spend ten minutes fixing a workflow than spend a weekend wondering how an attacker got out of a container.

Join the conversation