CVE feed → CVE-2026-31431

CVE-2026-31431 — Linux kernel algif_aead in-place revert

Linux kernel crypto subsystem vulnerability. The algif_aead userspace AEAD interface reverts to operating out-of-place after the previous in-place implementation mishandled associated data across user/kernel sphere boundaries. Local privilege escalation surface; not remotely exploitable. Patched in stable kernel branches; pick up via normal distro kernel updates.

TL;DR

• Local attack only (CVSS AV:L). Attacker needs an existing low-privilege user account on the host.
• CISA KEV-listed as of 2026-05-01 — known exploited in the wild; federal mitigation deadline was 2026-05-15.
• Vector: the AF_ALG socket family's algif_aead module, which exposes kernel-side AEAD ciphers (AES-GCM, ChaCha20-Poly1305, etc.) to userspace.
• CISA added this CVE to the KEV catalog on 2026-05-01 (mitigation deadline 2026-05-15) — actively exploited in the wild, treat as urgent regardless of your local threat model.
• Risk to a single-operator homelab where only you have shell access: meaningfully lower in practice (the LPE primitive requires a local user account), but the KEV listing means adversaries are now chaining it behind any unauthenticated RCE elsewhere on the box. Patch on the next maintenance window at the latest.
• Risk to multi-user / sandboxed / container / dev boxes: high — patch immediately.
• Fix: apply your distro's latest kernel security update, reboot. No special action needed beyond the usual cadence.

At a glance

What the kernel actually changed

From the upstream commit message:

crypto: algif_aead - Revert to operating out-of-place

This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.

Plain-English read: the algif_aead path's in-place mode had become a source of cross-sphere resource transfer bugs (CWE-669). The simpler out-of-place implementation removes the problematic code path entirely. The CVE is being assigned to the revert as the canonical security fix.

Per-distro fix status

Fix versions land via the normal kernel security update channels. Cross-reference the running kernel against your distro's tracker:

Quick check on a host

Determine the running kernel version and whether the system has a newer one installed but not yet booted:

# Running kernel:
uname -r

# Installed but not yet running (the answer tells you to reboot):
# Debian / Ubuntu
ls /boot/vmlinuz-* | sort -V | tail -1

# RHEL / Rocky / AlmaLinux
rpm -q --last kernel | head -2

# Reboot required indicator on Debian/Ubuntu:
[ -f /var/run/reboot-required ] && echo "REBOOT REQUIRED" || echo "No pending reboot"

Mitigations short of patching

If you can't reboot immediately, the exposure is limited to users who can open AF_ALG sockets. Two mitigations:

1. Block AF_ALG via seccomp / LSM for any user account that doesn't need cryptographic kernel access (almost no userspace tool does — most use OpenSSL / libsodium directly, not AF_ALG).
2. Unload the module if no service uses it: sudo rmmod algif_aead (will fail if in use; check with lsmod | grep algif_aead). Blacklist it to prevent reload: add blacklist algif_aead to /etc/modprobe.d/blacklist-algif.conf.

Both are workarounds, not fixes. Patch as soon as the kernel update window opens.

What Noxen does about this

Noxen flags every host whose installed kernel package is older than the per-distro fix version listed in its tracker. Because this is a kernel CVE, the package name varies by distro (linux-image-* on Debian/Ubuntu, kernel on RHEL-family), but Noxen's distro-aware matcher normalises both to the same CVE record.

Hosts that have the fix installed but haven't rebooted are flagged separately as "kernel updated but not yet running" so a reboot is queued explicitly rather than implicitly assumed after a package upgrade.

Authoritative sources

• NVD entry for CVE-2026-31431
• cve.org record
• FIRST EPSS API for CVE-2026-31431
• CISA KEV catalogue — added 2026-05-01 (mitigation due 2026-05-15)
• Stable kernel branch backport commits (from NVD references):
  • 19d4310…
  • 3115af9…
  • 893d22e…
  • 8b88d99…
  • 961cfa2…
  • a664bf3…
  • ce42ee4…
  • fafe0fa…

Related on Noxen

• Dirty Frag (CVE-2026-43284 / CVE-2026-43500) — the later twin kernel LPEs, same patch-and-reboot remediation
• Dirty Frag explained — embargo break, public PoC, and who is actually exposed
• Ubuntu 24.04 CVE tracker — including this CVE and other recent kernel issues
• How to triage CVE findings — when AV:L Highs warrant immediate action vs scheduled cycle
• The patching gap — kernel updates are the easy half; third-party services are the hard half

Frequently asked

What is CVE-2026-31431?

A Linux kernel crypto subsystem vulnerability in algif_aead. The kernel reverts commit 72548b093ee3 to stop operating in-place — the in-place mode added complexity around associated-data handling without performance benefit, and the revert closes the resulting security gap. CVSS 3.1 base score 7.8 (HIGH), CWE-669 (Incorrect Resource Transfer Between Spheres).

Is CVE-2026-31431 remotely exploitable?

No. The CVSS vector is AV:L (Local) — exploitation requires the attacker to already have a local user account or code execution on the target host. Low-privilege users (PR:L) can use the algif_aead interface via AF_ALG sockets, so the exposure window is any system that grants untrusted users shell access.

Does CVE-2026-31431 affect my homelab?

Depends on threat model. Single-operator homelabs where only you have shell access: low immediate risk. Hosts that grant guest or container-user shell access (multi-user dev boxes, Jupyter notebooks with shell access, sandboxed accounts): higher risk — patch promptly. Update the kernel via your distro's normal channels (apt full-upgrade / dnf upgrade) and reboot.

How do I tell if my kernel is patched?

Run uname -r to see the running kernel. Then compare against your distro's CVE tracker (Ubuntu: ubuntu.com/security/CVE-2026-31431; Debian: security-tracker.debian.org; Red Hat / Rocky / AlmaLinux: access.redhat.com/security/cve/CVE-2026-31431). The fix has been backported to stable kernel branches via 8 separate commits — the per-distro tracker is the authoritative source for whether your specific kernel build includes them.

See what Noxen does about CVEs like this →   More on CVE management →