AEAD Socket Vulnerability: How to Patch Your Linux Homelab Kernel Right Now

A use-after-free bug in the Linux kernel’s AEAD (Authenticated Encryption with Associated Data) socket implementation was recently disclosed and documented on LWN. If you’re running a homelab with Linux hosts — bare metal, VMs, or Proxmox nodes — you need to act now. This isn’t theoretical: local privilege escalation from an unprivileged user to root is within scope for this class of vulnerability.

This guide cuts straight to the fix.

---

Step 1: Check Your Kernel Version

Before touching anything, confirm what you’re running:

uname -r

Example output:

6.1.85-1-pve

Also check whether the AF_ALG socket interface is exposed:

grep -i alg /proc/net/protocols

If ALG appears in the output, your kernel has the crypto socket subsystem active. Most distros enable this by default.

---

Step 2: Determine If You’re Affected

The vulnerability lives in the kernel’s crypto/algif_aead.c code path. The fix was merged upstream and has been backported into LTS branches. Here’s how to check per distro:

Debian / Ubuntu:

apt-get changelog linux-image-$(uname -r) 2>/dev/null | grep -i "CVE\|aead\|algif" | head -20

Or check the USN / DSA tracker:

• Ubuntu: https://ubuntu.com/security/notices
• Debian: https://security-tracker.debian.org/tracker/

Fedora / RHEL / Rocky:

dnf updateinfo list --security | grep kernel

Arch Linux:

pacman -Si linux | grep Version

Cross-reference with the Arch Linux security advisories.

If your running kernel predates the patch and the ALG socket interface is active, treat yourself as affected until proven otherwise.

---

Step 3: Apply the Patch

Debian / Ubuntu

sudo apt update
sudo apt upgrade linux-image-generic linux-headers-generic
# Or for a specific installed kernel:
sudo apt full-upgrade

After upgrade, confirm the new image is staged:

dpkg -l | grep linux-image

Then reboot:

sudo reboot

Fedora / RHEL / Rocky Linux / AlmaLinux

sudo dnf update kernel
sudo reboot

If you want kernel-only (no other package updates):

sudo dnf update --security
sudo reboot

Arch Linux

sudo pacman -Syu linux linux-headers
sudo reboot

If you’re on linux-lts:

sudo pacman -Syu linux-lts linux-lts-headers
sudo reboot

---

Step 4: Verify the Patch Applied

After reboot, confirm you’re on the new kernel:

uname -r

Then re-check the ALG protocol exposure:

grep -i alg /proc/net/protocols

For a more targeted verification, check whether the vulnerable symbol has been patched by inspecting the kernel’s build config or changelog:

# Debian/Ubuntu
zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API_AEAD

Expected output if the feature is enabled (patched version):

CONFIG_CRYPTO_USER_API_AEAD=m

If you want to confirm via the changelog on Debian-based systems:

apt-get changelog linux-image-$(uname -r) 2>/dev/null | grep -A2 "aead\|algif" | head -30

---

Automation: Script It Across Multiple Hosts

If you’re managing several homelab nodes, use this wrapper to check and update all of them:

#!/usr/bin/env bash
# patch-kernel.sh — run on each host or via parallel-ssh

set -euo pipefail

CURRENT_KERNEL=$(uname -r)
echo "[*] Current kernel: $CURRENT_KERNEL"

if command -v apt &>/dev/null; then
  echo "[*] Detected Debian/Ubuntu — running apt upgrade"
  sudo apt update -qq
  sudo apt upgrade -y linux-image-generic linux-headers-generic
elif command -v dnf &>/dev/null; then
  echo "[*] Detected Fedora/RHEL — running dnf update"
  sudo dnf update -y kernel
elif command -v pacman &>/dev/null; then
  echo "[*] Detected Arch — running pacman"
  sudo pacman -Syu --noconfirm linux linux-headers
else
  echo "[!] Unknown package manager. Update manually."
  exit 1
fi

echo "[*] Update complete. Reboot required."
echo "[*] Run: sudo reboot"

Make it executable and run it:

chmod +x patch-kernel.sh
./patch-kernel.sh

---

Bonus: Patching Proxmox VE Nodes

Proxmox uses its own kernel packages (pve-kernel-*) maintained by the Proxmox team. They track upstream LTS kernels and apply security patches, but you need to update explicitly.

Check what’s installed on your PVE node:

proxmox-boot-tool kernel list

Update the PVE kernel:

apt update
apt dist-upgrade

This will pull the latest pve-kernel package. Proxmox typically names these like pve-kernel-6.8.12-4-pve.

Before rebooting a Proxmox host:

1. Migrate or shut down VMs/CTs on the node you’re about to reboot.
2. Confirm the new kernel is pinned in the boot tool:

proxmox-boot-tool kernel pin $(proxmox-boot-tool kernel list | grep pve | sort -V | tail -1)
proxmox-boot-tool refresh

3. Reboot:

reboot

4. After coming back up:

uname -r
proxmox-boot-tool kernel list

Confirm you’re on the patched kernel. In a cluster, repeat this process node by node — never reboot all nodes simultaneously.

Proxmox Cluster Health Check After Patching:

pvecm status
ha-manager status

Both should show quorum and HA services healthy before you move to the next node.

---

Mitigation If You Can’t Reboot Immediately

If a production service makes immediate rebooting impossible, you can temporarily block unprivileged access to AF_ALG sockets using a seccomp profile or by restricting socket creation via a cgroup/systemd hardening rule. However, this is a workaround, not a fix:

# Load a seccomp filter or use systemd unit hardening
# Add to /etc/systemd/system/yourservice.service under [Service]:
# SystemCallFilter=~socket

This is imperfect. Patch and reboot as soon as your maintenance window allows.

---

What’s Next

• /homelab/proxmox-ve-hardening-guide — Lock down your Proxmox environment beyond the defaults
• /homelab/linux-firewall-nftables-homelab — Replace iptables with nftables for modern homelab network control
• /homelab/kernel-live-patching-kpatch-homelab — Apply kernel patches without rebooting using kpatch or livepatch
• /aws/ec2-linux-security-patching-automation — Automate kernel patching across EC2 Linux instances with SSM Patch Manager