diff --git a/target/linux/generic/pending-6.18/928-crypto-eip93-fix-hmac-setkey-algo-selection.patch b/target/linux/generic/pending-6.18/928-crypto-eip93-fix-hmac-setkey-algo-selection.patch
new file mode 100644
index 0000000000..66a9356854
--- /dev/null
+++ b/target/linux/generic/pending-6.18/928-crypto-eip93-fix-hmac-setkey-algo-selection.patch
@@ -0,0 +1,82 @@
+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);
+