Kernel updates — what every container inherits from the host

A virtual machine has its own kernel, so patching the hypervisor’s kernel and patching the guest are independent operations. A container does not. Every container on a Docker host is executing syscalls against the host’s single kernel, and the entire isolation model is kernel features.

That makes the host kernel simultaneously the most security-relevant component on the machine and the one that cannot be updated without stopping everything.

What the containers are using

$ docker run --rm alpine:3.20 uname -r

6.8.0-51-generic

Compare that with uname -r on the host and they are identical, always. The image’s own distribution version is irrelevant to this: an Ubuntu 20.04 container on a host running a 6.8 kernel is using 6.8.

Every one of these is a kernel feature the container depends on:

A kernel with any of these misconfigured or missing is a host on which Docker either refuses to start containers or starts them with less isolation than you think.

Installed is not running

The distinction that makes kernel patching reporting so misleading:

# What is actually executing right now
uname -r

# Every kernel image installed
dpkg -l 'linux-image-*' | awk '/^ii/ {print $2, $3}'

# Ubuntu and Debian drop this file when a reboot is needed
ls -l /var/run/reboot-required /var/run/reboot-required.pkgs 2>/dev/null
cat /var/run/reboot-required.pkgs 2>/dev/null

$ uname -r; cat /var/run/reboot-required.pkgs

6.8.0-51-generic
linux-image-6.8.0-52-generic
linux-base

An automatic patching job that installs kernels without rebooting produces exactly this state, indefinitely. The package database says the host is fully patched. The running kernel is whatever it booted with, possibly months ago.

# Report only; restarts nothing
sudo needrestart -r l

# Kernel only, batch output for monitoring
sudo needrestart -k -b

Live patching, and its limits

Ubuntu Livepatch and kpatch apply certain kernel fixes to a running kernel without a reboot. On a Docker host this is genuinely valuable, because the alternative is stopping every container.

It is not a replacement for rebooting.

Kernel changes that break Docker

Rare, but worth knowing the shape of:

• Booting an older kernel from the GRUB menu to work around something, on a host whose Docker installation needs a feature the older kernel lacks. cgroup v2 is the usual casualty and the daemon may fall back to v1 with different limit semantics.
• A cgroup v1 to v2 transition, whether from a distribution upgrade or a systemd.unified_cgroup_hierarchy kernel parameter. Resource limits are expressed differently between the two and the daemon reports the mode in docker info.
• A storage driver whose prerequisites the new kernel no longer satisfies. Almost never on overlay2; more plausible on btrfs or zfs where the module must match the kernel.

uname -r
docker info --format 'cgroup={{.CgroupVersion}} driver={{.CgroupDriver}} storage={{.Driver}}'
docker info 2>&1 | grep -iE 'warning|no swap|no cpu' || echo 'no daemon warnings'

docker info prints warnings for missing kernel capabilities — the classic being WARNING: No swap limit support on a host booted without swapaccount=1. A warning that appears after a kernel change and was not there before is the fastest signal that the reboot changed something.

Knowledge check