CVE-2026-53302

What it actually does

This is a Linux kernel denial-of-service flaw in the EIP93 hardware crypto driver. During HMAC key setup, the driver attempts to allocate an asynchronous hash transform while applying a mask that excludes asynchronous algorithms, causing the lookup to fail. In the AEAD setkey path, that failure can leave security association state only partially initialized, including zeroed or missing digest context fields. A later crypto operation can then dereference a NULL request-context pointer in kernel space, resulting in an oops or kernel panic. The practical technical outcome is system crash or reboot when affected EIP93-backed crypto paths are exercised.

Why it matters to the business

Systems using Linux kernels with the affected EIP93 crypto hardware driver may crash when specific hardware-accelerated crypto operations are triggered, interrupting network, VPN, storage, appliance, or embedded workloads that rely on kernel cryptography. The currently reported exploitation maturity is none, EPSS is very low, and it is not in CISA KEV or known ransomware use, so broad active exploitation is not indicated; however, affected embedded or appliance deployments can still experience high operational impact because a kernel panic can take the entire device or service offline.

How an attack unfolds

An attacker or untrusted local workload must be able to cause the vulnerable kernel to create and use an AEAD/HMAC operation backed by the EIP93 hardware crypto driver. The vulnerable setkey routine calls crypto_alloc_ahash() with contradictory algorithm-selection constraints, causing allocation to fail for driver-specific asynchronous hashes such as EIP93-backed SHA variants. Instead of leaving fully valid crypto state, the AEAD setkey path can proceed with partially initialized security association data. When a subsequent encryption, decryption, authentication, or completion path processes that state, the driver resolves a transform context to NULL and attempts to read from it in kernel mode. That NULL pointer dereference causes a kernel crash, producing a denial of service. Remote exploitation would generally depend on whether a remotely reachable service, protocol, or appliance function can be made to exercise the affected EIP93 AEAD/HMAC path; otherwise, exploitation is more likely through local or privileged configuration paths that expose kernel crypto operations.

How to fix it

Apply a Linux kernel update that includes the EIP93 driver fix for HMAC setkey algorithm selection. Where vendor kernels are used, install the relevant distribution, appliance, SoC vendor, or embedded Linux firmware update rather than attempting to patch only the module manually. If an immediate update is not available, consider disabling the EIP93 hardware crypto driver or preventing its algorithms from being selected, if operationally acceptable. As a temporary risk reduction, avoid exposing untrusted users or remote services to interfaces that can trigger EIP93-backed AEAD/HMAC operations, and prefer software crypto implementations until patched. Reboot after kernel or module updates when required so the fixed driver is active.

How to confirm the fix worked

Confirm whether the running kernel includes the vendor fix for the EIP93 HMAC setkey crypto_alloc_ahash() behavior. Check whether the EIP93 driver is loaded or built in, for example by reviewing loaded modules, kernel configuration, boot logs, and /proc/crypto entries for EIP93-backed algorithms. After remediation, verify that crypto operations using affected AEAD/HMAC paths complete without kernel oops, panic, or -ENOENT allocation failures. On managed distributions, validate by comparing the installed kernel package or firmware image against the vendor advisory and confirming the running kernel version after reboot. In test environments, exercise representative VPN/IPsec or crypto workloads that previously selected EIP93 acceleration and monitor dmesg/journal logs for crashes or EIP93 errors.

Typical attack path

1. Identify a Linux-based device or appliance using the EIP93 hardware crypto driver.
2. Find a reachable code path that invokes EIP93-backed AEAD/HMAC operations, such as kernel crypto API users, IPsec/VPN functions, appliance cryptographic services, or local AF_ALG-style crypto access where available.
3. Trigger key setup for an affected HMAC/AEAD algorithm using the EIP93 driver-specific implementation.
4. Cause a follow-on crypto operation using the partially initialized state.
5. The kernel dereferences a NULL pointer in the EIP93 result-handling path and panics, causing denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal data, crash dumps, netconsole output, serial console logs, appliance support bundles, and monitoring events for kernel oops or panic records involving the EIP93 crypto driver. Focus on crashes that occur immediately after VPN/IPsec, AEAD, HMAC, encryption, authentication, or hardware crypto activity. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore analysis, kernel panic watchdog events, and appliance-specific crash reports. Look for stack traces containing crypto_hw_eip93 or eip93_aead_handle_result, NULL pointer dereferences, failed ahash allocation behavior, and crashes around AEAD result handling. Because the described failure is a denial-of-service crash and not a code-execution primitive, indicators are primarily crash artifacts and kernel log strings rather than files dropped by an attacker.

• crypto_hw_eip93
• eip93_aead_handle_result
• eip93_hmac_setkey
• eip93_hash_ctx
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• kernel panic
• Oops:
• pc : eip93_aead_handle_result
• eip93_aead_handle_result+0xc8c
• LDR X0, [X26, #0x8]
• crypto_alloc_ahash
• sha256-eip93
• -ENOENT

What your security team should do

• Inventory Linux, embedded, network appliance, and SoC-based systems that may include the EIP93 hardware crypto driver.
• Prioritize patching internet-facing, remotely managed, VPN, gateway, storage, and high-availability systems where a crash would cause material outage.
• Because this is not KEV-listed, has no known ransomware use, and has very low EPSS, schedule remediation according to normal kernel-update SLAs unless the affected driver is present on critical appliances.
• If patching is delayed, assess whether EIP93 acceleration can be disabled or software crypto can be preferred without unacceptable performance impact.
• Restrict untrusted local access to kernel crypto interfaces and review exposed services that may drive AEAD/HMAC operations through the kernel crypto API.
• Monitor for kernel panics or oops messages referencing crypto_hw_eip93, eip93_aead_handle_result, eip93_hmac_setkey, or NULL pointer dereferences in crypto paths.
• Coordinate with appliance and firmware vendors, since affected code may be delivered through downstream kernel forks rather than mainline package names.