CVE-2026-53302

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: eip93 - fix hmac setkey algo selection<br /> <br /> eip93_hmac_setkey() allocates a temporary ahash transform for<br /> computing HMAC ipad/opad key material. The allocation uses the<br /> driver-specific cra_driver_name (e.g. "sha256-eip93") but passes<br /> CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms.<br /> <br /> Since the EIP93 hash algorithms are the only ones registered<br /> under those driver names and they are inherently async, the<br /> lookup is self-contradictory and always fails with -ENOENT.<br /> <br /> When called from the AEAD setkey path, this failure leaves the<br /> SA record partially initialized with zeroed digest fields. A<br /> subsequent crypto operation then dereferences a NULL pointer in<br /> the request context, resulting in a kernel panic:<br /> <br /> ```<br /> pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93]<br /> lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93]<br /> sp : ffffffc082feb820<br /> x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980<br /> x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0<br /> x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000<br /> x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f<br /> x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009<br /> x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0<br /> Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740)<br /> ```<br /> <br /> The reported symbol eip93_aead_handle_result+0xc8c is a<br /> resolution artifact from static functions being merged under<br /> the nearest exported symbol. Decoding the faulting sequence:<br /> <br /> ```<br /> 910142b6 ADD X22, X21, #0x50<br /> f94012e0 LDR X0, [X23, #0x20]<br /> f9002aa0 STR X0, [X21, #0x50]<br /> f90006d3 STR X19, [X22, #0x8]<br /> f9400740 LDR X0, [X26, #0x8]<br /> ```<br /> <br /> The faulting LDR at [X26, #0x8] is loading ctx-&gt;flags<br /> (offset 8 in eip93_hash_ctx), where ctx has been resolved<br /> to NULL from a partially initialized or unreachable<br /> transform context following the failed setkey.<br /> <br /> Fix this by dropping the CRYPTO_ALG_ASYNC mask from the<br /> crypto_alloc_ahash() call. The code already handles async<br /> completion correctly via crypto_wait_req(), so there is no<br /> requirement to restrict the lookup to synchronous algorithms.<br /> <br /> Note that hashing a single 64-byte block through the hardware<br /> is likely slower than doing it in software due to the DMA<br /> round-trip overhead, but offloading it may still spare CPU<br /> cycles on the slower embedded cores where this IP is found.<br /> <br /> [Detailed investigation report of this bug]