--- /dev/null
+From: Aleksander Jan Bajkowski <olek2@wp.pl>
+Date: Sat, 11 Apr 2026 23:08:17 +0200
+Subject: [PATCH] crypto: inside-secure/eip93 - eip93: fix hmac setkey algo
+ selection
+
+eip93_hmac_setkey() allocates a temporary ahash transform for
+computing HMAC ipad/opad key material. The allocation uses the
+driver-specific cra_driver_name (e.g. "sha256-eip93") but passes
+CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms.
+
+Since the EIP93 hash algorithms are the only ones registered
+under those driver names and they are inherently async, the
+lookup is self-contradictory and always fails with -ENOENT.
+
+When called from the AEAD setkey path, this failure leaves the
+SA record partially initialized with zeroed digest fields. A
+subsequent crypto operation then dereferences a NULL pointer in
+the request context, resulting in a kernel panic:
+
+```
+ pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93]
+ lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93]
+ sp : ffffffc082feb820
+ x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000
+ x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980
+ x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0
+ x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000
+ x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498
+ x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
+ x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000
+ x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f
+ x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009
+ x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0
+ Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740)
+```
+
+The reported symbol eip93_aead_handle_result+0xc8c is a
+resolution artifact from static functions being merged under
+the nearest exported symbol. Decoding the faulting sequence:
+
+```
+ 910142b6 ADD X22, X21, #0x50
+ f94012e0 LDR X0, [X23, #0x20]
+ f9002aa0 STR X0, [X21, #0x50]
+ f90006d3 STR X19, [X22, #0x8]
+ f9400740 LDR X0, [X26, #0x8]
+```
+
+The faulting LDR at [X26, #0x8] is loading ctx->flags
+(offset 8 in eip93_hash_ctx), where ctx has been resolved
+to NULL from a partially initialized or unreachable
+transform context following the failed setkey.
+
+Fix this by dropping the CRYPTO_ALG_ASYNC mask from the
+crypto_alloc_ahash() call. The code already handles async
+completion correctly via crypto_wait_req(), so there is no
+requirement to restrict the lookup to synchronous algorithms.
+
+Note that hashing a single 64-byte block through the hardware
+is likely slower than doing it in software due to the DMA
+round-trip overhead, but offloading it may still spare CPU
+cycles on the slower embedded cores where this IP is found.
+
+Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support")
+Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
+[Detailed investigation report of this bug]
+Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
+---
+ drivers/crypto/inside-secure/eip93/eip93-common.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/inside-secure/eip93/eip93-common.c
++++ b/drivers/crypto/inside-secure/eip93/eip93-common.c
+@@ -731,7 +731,7 @@ int eip93_hmac_setkey(u32 ctx_flags, con
+ return -EINVAL;
+ }
+
+- ahash_tfm = crypto_alloc_ahash(alg_name, 0, CRYPTO_ALG_ASYNC);
++ ahash_tfm = crypto_alloc_ahash(alg_name, 0, 0);
+ if (IS_ERR(ahash_tfm))
+ return PTR_ERR(ahash_tfm);
+