CVE-2026-46028

What it actually does

This is a local Linux kernel race condition in the AF_ALG AEAD crypto interface. Asynchronous AEAD requests incorrectly reference a socket-wide initialization vector buffer while the request is still in flight. A local user with permission to access AF_ALG can submit asynchronous AEAD operations and then modify socket state before the original operation completes, causing inconsistent IV handling. Based on the assigned CVSS vector, the expected security impact is denial of service rather than confidentiality or integrity compromise: malformed or inconsistent in-kernel crypto state may trigger request failures, kernel warnings, hangs, or crashes.

Why it matters to the business

Successful exploitation can disrupt Linux systems by causing local denial of service, potentially taking workloads offline or forcing reboots. The issue requires local access, so internet-facing remote exploitation is not expected; however, multi-user systems, shared compute nodes, container hosts, CI/CD runners, and environments that allow untrusted local code are more exposed. The EPSS score is currently very low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated, but kernel availability flaws should still be prioritized where local untrusted users or sandboxed workloads run on shared hosts.

How an attack unfolds

An attacker first obtains the ability to run code locally on a vulnerable Linux system. They open an AF_ALG socket using an AEAD algorithm and issue asynchronous encryption or decryption requests through the kernel crypto API. While one or more AEAD AIO requests are still pending, the attacker performs additional socket operations that alter the socket-wide IV state. Because vulnerable kernels use that mutable shared IV buffer during asynchronous request processing instead of copying it into per-request storage, the in-flight request can observe inconsistent state. By repeatedly racing request submission and IV updates, the attacker attempts to drive the kernel crypto path into an error, hang, warning, or crash condition, resulting in local denial of service.

How to fix it

Update the Linux kernel to a version that includes the upstream fix for algif_aead to snapshot the IV into per-request storage for asynchronous AEAD requests. If distribution-specific fixed package versions are not available, use the vendor kernel advisory for the affected distribution and install the latest security-supported kernel containing the AF_ALG AEAD fix. Reboot systems after installing the updated kernel, or live-patch only if the vendor explicitly provides a live patch for this issue. As interim mitigation, reduce exposure to untrusted local code: restrict shell access, isolate untrusted workloads, limit shared multi-user access, and apply container hardening. Where operationally feasible, prevent untrusted users from accessing kernel crypto AF_ALG interfaces using sandboxing, seccomp, LSM policy, or workload isolation controls.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that includes the algif_aead asynchronous AEAD IV snapshot fix; checking only the installed package is insufficient if the host has not rebooted into the fixed kernel. Validate with `uname -r`, package manager query output, and the relevant distribution security advisory. If source validation is possible, confirm the kernel crypto AF_ALG AEAD implementation copies the IV into per-request storage during request preparation rather than relying on mutable socket-wide IV state for in-flight asynchronous requests. For exposure assessment, identify systems that allow local untrusted code execution and have AF_ALG enabled. After patching, run regression or crypto workload tests that exercise AF_ALG AEAD asynchronous operations and monitor for kernel warnings, oopses, or hangs.

Typical attack path

1. Gain local code execution on a vulnerable Linux host, such as through a shell, compromised user account, container escape-adjacent workload, or untrusted local job execution.
2. Create an AF_ALG socket for an AEAD crypto algorithm supported by the kernel.
3. Submit asynchronous AEAD encryption or decryption requests.
4. Rapidly update or reuse the socket IV state while earlier requests remain in flight.
5. Repeat the race to trigger inconsistent IV handling in the kernel crypto path.
6. Cause service disruption, kernel instability, or a host crash requiring recovery or reboot.

How to detect it

Retrospective detection is difficult because exploitation may leave only generic local activity and kernel failure artifacts. Review kernel logs, system journal, crash dumps, and audit telemetry for signs of AF_ALG or algif_aead activity followed by kernel warnings, oopses, hung tasks, panics, spontaneous reboots, or service outages. Useful log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, pstore, kdump/vmcore, auditd syscall logs, EDR process telemetry, and container runtime logs. Look for local processes repeatedly creating AF_ALG sockets, using AEAD algorithms, issuing asynchronous I/O, or crashing shortly before a kernel panic. Because no public exploit signature is known, correlate suspicious indicators with local user sessions, container starts, CI jobs, or recently executed binaries. If kernel crash dumps are available, inspect stack traces for AF_ALG, algif_aead, AEAD, crypto, or AIO request-processing functions.

• algif_aead
• AF_ALG
• af_alg
• aead
• aead_recvmsg
• aead_sendmsg
• crypto_aead
• crypto: algif_aead
• BUG: kernel
• kernel BUG
• Oops:
• kernel NULL pointer dereference
• general protection fault
• Kernel panic
• watchdog: BUG: soft lockup
• INFO: task
• blocked for more than
• hung_task
• rcu_sched detected stalls
• socket(AF_ALG
• /proc/crypto
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/fs/pstore
• /var/crash

What your security team should do

• Prioritize patching shared Linux systems where untrusted or semi-trusted users can run local code, including container hosts, build workers, research clusters, bastion hosts, and multi-tenant compute nodes.
• Inventory vulnerable Linux kernels across the fleet and map them to vendor advisories because fixed versions are distribution-specific.
• Schedule reboots after kernel updates and verify the active running kernel is the fixed version.
• If immediate patching is not possible, reduce local attack surface by restricting interactive access, tightening workload isolation, and applying seccomp/LSM controls to block unnecessary AF_ALG socket usage by untrusted processes.
• Monitor kernel logs for AF_ALG, algif_aead, crypto, AIO, oops, panic, or hung-task events that coincide with local user activity.
• Treat repeated local kernel crashes involving crypto or AF_ALG paths as suspicious even though public exploit maturity is currently listed as none and EPSS is low.
• Include this vulnerability in container-host and shared-compute risk reviews because local kernel denial-of-service bugs can affect all workloads on the same host.