CVE-2026-46033

What it actually does

This is a local Linux kernel memory-corruption flaw in the crypto API’s authencesn AEAD template. authencesn requires either an authentication tag size of 0 or at least 4 bytes, because the ESN encrypt/decrypt paths always handle 4 bytes of high-order sequence-number data at the end of the authenticated data. During instance creation, the kernel failed to reject hash algorithms with digest sizes of 1 to 3 bytes, allowing an invalid default authsize to be inherited. A local user able to reach the kernel crypto API, including through AF_ALG, could create a malformed authencesn instance and trigger out-of-bounds memory access. The likely impacts are kernel memory disclosure and denial of service through a kernel crash or oops; integrity impact is not indicated by the supplied scoring.

Why it matters to the business

Successful exploitation can allow a local authenticated user, including potentially a compromised low-privileged account or containerized workload with AF_ALG access, to crash the host kernel or expose sensitive kernel memory. For organizations running multi-user Linux systems, shared compute, CI runners, container platforms, VPN/IPsec infrastructure, or appliances that expose Linux crypto functionality to local processes, this can translate into service outages, host instability, incident response effort, and possible leakage of sensitive data from kernel memory. The vulnerability is not currently listed in CISA KEV, is not known from the provided data to be used in ransomware campaigns, and has a very low EPSS score, so urgency is lower than internet-facing actively exploited issues; however, kernel fixes should still be prioritized where untrusted local code can run.

How an attack unfolds

An attacker first obtains local code execution with low privileges on a vulnerable Linux system. They then interact with the kernel crypto API, typically via AF_ALG sockets, and request an authencesn AEAD construction using an ahash algorithm whose digest size is in the invalid 1-to-3 byte range, such as a construction similar to cbcmac(cipher_null). Because vulnerable kernels copied the ahash digest size into the AEAD instance’s maximum authentication size without validating this short non-zero value, the created transform can inherit an unsupported default authsize. The attacker then submits AEAD encrypt or decrypt operations that exercise the ESN tail-handling logic. That code assumes it can move 4 bytes of high-order sequence-number data, but the tag is shorter than 4 bytes, causing an out-of-bounds access. Depending on kernel build, allocator state, hardening, and runtime checks, the result may be a kernel oops, panic, KASAN report, service outage, or exposure of adjacent kernel memory.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the authencesn fix rejecting ahash digest sizes in the invalid non-zero range of 1 to 3 bytes during instance creation. No exact fixed package versions were provided, so use vendor advisories and changelogs for the affected distribution, kernel stream, cloud image, or embedded/appliance firmware. Reboot into the patched kernel after installation; merely installing the package is insufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by preventing untrusted local code from using AF_ALG: apply seccomp profiles that deny socket(AF_ALG, ...), restrict container privileges, avoid running untrusted workloads on shared hosts, and consider disabling or blacklisting nonessential AF_ALG/AEAD crypto modules such as algif_aead where operationally safe. Validate compatibility before disabling crypto modules, because IPsec, VPN, storage, and application crypto workflows may depend on them.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the vendor fix. Use uname -a and package-manager tooling such as rpm -q --changelog, dpkg changelogs, apt/yum/dnf/zypper advisory metadata, or vendor live-patch status to verify the backported patch is present. Check whether exposure-relevant components are available by reviewing /proc/crypto for authencesn-related algorithms and loaded modules such as algif_aead. In a non-production test environment, a safe validation should confirm that attempts to instantiate authencesn with an ahash digest size in the invalid 1-to-3 byte range fail during instance creation rather than allowing a transform to be created. After remediation, verify the host has rebooted into the fixed kernel and review kernel logs to ensure no new authencesn, AF_ALG, KASAN, BUG, or Oops messages appear during crypto API testing.

Typical attack path

1. Gain local execution on a vulnerable Linux host as an authenticated low-privileged user or through a compromised local workload.
2. Determine that AF_ALG and the relevant kernel crypto algorithms/templates are available or can be autoloaded.
3. Create or request an authencesn AEAD instance backed by an ahash algorithm with a digest size of 1 to 3 bytes.
4. Use AF_ALG or another local crypto API path to perform AEAD operations with the malformed instance and invalid inherited authsize.
5. Trigger the ESN tail-handling path, causing out-of-bounds kernel memory access.
6. Leverage the result for denial of service through a kernel crash/oops or for possible kernel memory disclosure.

How to detect it

To assess whether exploitation may already have occurred, review host-level kernel telemetry rather than network perimeter logs, because exploitation is local. Examine journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg captures, crash dumps, kdump/vmcore records, and EDR telemetry for kernel oopses, panics, KASAN/UBSAN reports, or BUG messages referencing authencesn, authenc_esn, crypto_authenc_esn, algif_aead, af_alg, or AF_ALG socket activity. If Linux auditd or EDR syscall telemetry is available, look for unusual local processes creating AF_ALG sockets, especially followed by kernel faults or repeated crypto API errors. In container platforms, correlate suspicious pod/container restarts, node NotReady events, kernel panics, or seccomp denials involving AF_ALG with local processes that should not be using kernel crypto sockets. Absence of logs does not prove absence of exploitation, because a successful memory disclosure may not crash the system and AF_ALG socket use is not logged by default on many systems.

• authencesn
• authenc_esn
• crypto_authenc_esn
• crypto_authenc_esn_create
• crypto_authenc_esn_setauthsize
• algif_aead
• af_alg
• AF_ALG
• cbcmac(cipher_null)
• socket(AF_ALG
• KASAN:
• BUG: kernel
• Oops:
• kernel panic
• /proc/crypto
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems that allow untrusted local users, containers, CI jobs, plugins, or workloads to execute code, and prioritize those for kernel updates.
• Patch and reboot affected Linux hosts using vendor kernel packages or live-patching mechanisms that explicitly include the authencesn validation fix.
• For container and shared-compute environments, add or verify seccomp controls that block socket creation with AF_ALG unless there is a documented need.
• Review whether algif_aead and related crypto API modules are required; disable or blacklist nonessential modules only after testing for application, VPN, IPsec, and storage impact.
• Monitor kernel logs and crash telemetry for authencesn, AF_ALG, algif_aead, KASAN, BUG, Oops, or panic events that may indicate attempted exploitation or fuzzing.
• Because EPSS is low and the issue is not KEV-listed, treat this as a prioritized kernel hardening and local-privilege exposure issue rather than an emergency internet-facing incident, unless the environment runs untrusted local workloads.