CVE-2026-43077

What it actually does

CVE-2026-43077 is a local Linux kernel denial-of-service flaw in the AF_ALG AEAD crypto socket implementation, specifically in algif_aead decryption receive handling. The vulnerable code checked the caller-provided receive buffer size without including the authentication tag length required for AEAD decryption. A local user able to access the kernel user-space crypto API could provide a receive buffer that passes the incorrect minimum-size validation but is still too small for the decrypted payload plus tag handling, potentially triggering kernel error paths, memory access faults, oops, or panic conditions. The expected impact is loss of availability; the advisory data does not indicate confidentiality or integrity compromise.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, causing service interruption for workloads running on those hosts. Because exploitation requires local privileges and there is no known public exploit maturity, KEV listing, ransomware association, or meaningful EPSS movement, broad internet-scale exploitation risk is currently low. However, shared Linux servers, multi-user systems, container hosts where untrusted users can execute local code, CI/build workers, and environments running untrusted workloads have higher operational exposure because a low-privileged local account may be sufficient to trigger host-level disruption.

How an attack unfolds

An attacker first obtains the ability to run code as a local, low-privileged user on an affected Linux host. They then interact with the Linux AF_ALG user-space crypto API and select an AEAD cipher path handled by algif_aead. During a decryption operation, the attacker crafts socket I/O so that the receive buffer appears to satisfy the vulnerable minimum-size check but does not account for the required authentication tag length. When the kernel processes the malformed decryption receive request, the incorrect size validation can lead to an invalid kernel state or fault, causing an oops, panic, or service-impacting kernel crash. The attack is local, requires no user interaction, and primarily affects system availability.

How to fix it

Update the Linux kernel to a vendor-maintained release that includes the algif_aead fix for AEAD decryption receive buffer size validation. Because no exact fixed versions were provided, use the applicable distribution security advisory or upstream stable kernel release notes to identify the first patched kernel for each platform. After installing the patched kernel, reboot into the updated kernel and remove or retire older vulnerable kernels where operationally feasible. As interim risk reduction, restrict local shell/code execution to trusted users, harden multi-user and container-host environments, and consider disabling or limiting access to the user-space crypto API/AEAD module only if your distribution and workloads allow it without breaking required functionality.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking `uname -r` after reboot and comparing it with the vendor-fixed kernel version. Review distribution advisories or kernel changelogs for the algif_aead fix described as accounting for AEAD tag size in the minimum receive buffer check. Check whether the host has AF_ALG AEAD exposure by reviewing kernel configuration and loaded modules, for example `CONFIG_CRYPTO_USER_API_AEAD`, `algif_aead`, and entries in `/proc/crypto`. Where feasible, validate in a non-production test system that malformed AF_ALG AEAD decryption requests are rejected cleanly rather than producing a kernel oops or panic. Confirm crash monitoring, kernel logging, and host health telemetry remain clean after update.

Typical attack path

1. Gain local code execution or shell access as a low-privileged user on an affected Linux system.
2. Confirm the kernel exposes the AF_ALG user-space crypto interface and supports AEAD algorithms.
3. Open and configure an AF_ALG crypto socket for an AEAD decryption operation.
4. Submit crafted decryption input and an undersized receive buffer that bypasses the flawed minimum-size check.
5. Trigger the vulnerable algif_aead receive/decryption path.
6. Cause kernel instability, oops, panic, or host-level denial of service.

How to detect it

Look for evidence of prior exploitation primarily in kernel and host crash telemetry, because this flaw is local and does not produce network indicators. Review `journalctl -k`, `dmesg`, `/var/log/kern.log`, `/var/log/messages`, crash dump systems, kdump/vmcore records, and EDR host telemetry for kernel oops, BUG, panic, KASAN, general protection fault, NULL pointer dereference, or slab/memory errors with stack traces referencing `algif_aead`, `af_alg`, AEAD crypto sockets, or decryption receive functions. If auditd, eBPF, or EDR syscall telemetry is available, search for unusual local processes creating AF_ALG sockets and rapidly calling sendmsg/recvmsg around the time of a kernel crash. Correlate crashes with recent low-privileged user sessions, CI jobs, container workloads, or suspicious local binaries. Absence of these artifacts does not prove non-exploitation, because a successful kernel panic may truncate logs unless persistent kernel logging or crash dumps are enabled.

• algif_aead
• af_alg
• AF_ALG
• aead_recvmsg
• crypto_aead_decrypt
• BUG: kernel
• kernel BUG
• Kernel panic
• Oops:
• general protection fault
• KASAN:
• /var/log/kern.log
• /var/crash/
• /proc/crypto
• CONFIG_CRYPTO_USER_API_AEAD

What your security team should do

• Prioritize patching Linux systems that allow untrusted local users, shared accounts, CI jobs, containers, sandboxed workloads, or third-party code execution.
• Track vendor-specific kernel advisories and deploy the first patched kernel available for each Linux distribution in use.
• Reboot systems after kernel update and verify the active running kernel is the patched version.
• Review whether untrusted workloads can access AF_ALG/user-space crypto interfaces and reduce that exposure where practical.
• Monitor kernel logs and crash telemetry for oops, panic, BUG, or KASAN reports involving algif_aead, af_alg, or AEAD decryption paths.
• Ensure local privilege boundaries are hardened, including least-privilege access, container isolation, seccomp/AppArmor/SELinux profiles, and restrictions on interactive shell access.
• Because EPSS is very low, no KEV entry exists, and no public exploit maturity is reported, treat this as important availability hardening rather than an emergency internet-facing incident unless local untrusted execution is common in the environment.