From nobody Fri Jul 24 05:22:04 2026 Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C0834D90A6 for ; Thu, 23 Jul 2026 15:08:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.125.188.122 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784819329; cv=none; b=SuXdcDjLv8b2EBdIZMlKxqpPzLhAXRIimF1n+T+P/Jyow90KnWiNAmjf32Vh9yMUNhk62B4RPpqyJU2i+jOPTrmM1Z0Eu1W0q4wI0n/kUwhPZDHCAa+xsv1UBggC77B0RyKInNkwuDxoA/7iDeXX7nAfaepqEUpSpbGBovung8I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784819329; c=relaxed/simple; bh=qhc8y1t7l2U3SC+fCFgvoGHLPrbpQK1AUYxe4zLkDcA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ssWhNjXLvTCxhl+5xvS1XqavTFPJ5THqMeKHUJ/RYWCToEkadPvz2LN7aDtz31FUIwQd8HHngVEdyZOim0tdPf+LYwehxdV/shj/AWm9f9sFUekQo8adzPn52T0qKMAl+h2Xzi3fFb+Uj90zuM8LMZl441NDXYNFSELSABfCq34= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=canonical.com; spf=pass smtp.mailfrom=canonical.com; dkim=pass (4096-bit key) header.d=canonical.com header.i=@canonical.com header.b=meC0Mefd; arc=none smtp.client-ip=185.125.188.122 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=canonical.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=canonical.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=canonical.com header.i=@canonical.com header.b="meC0Mefd" Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 35CF03FC27 for ; Thu, 23 Jul 2026 15:01:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20251003; t=1784818879; bh=rmn4iCRgd2W2Q1p9YGZBP63yr2RQlfKU8yIifwUIXo8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=meC0Mefdm4H8YejtIs88sRy/o7DNWuRLWNo0s+2amFrPpSPPRdmhPR6k5UEsE0ns1 ACCeep8TdsQMdU1LoSoZlQcRYurOP8/Q6OTMfVNC9RWVhesk5X2dru63afKK/kCw4Y gK0yrBzZ0YPghPLpxzkxFEz4gEDfDpwzs1tBV6JMlmisbHek7d8z61pNyhKCMUl7Ik jQTlHJJ4BZeT8aC0Gmt1PehXyvmfBh0LW0HjV/fYhsN+q4QV5iuJYxIZhY6rFRFtHA ZxbSMKARMx+02HEdNWqSUwpJwA5qbnwohNWBslFRwfpsHQSfC1QReFE99+ljaxBhX1 MbR/8g0CFPDaEnF6VDZPW6X7h9Yw7k7Jp/kktudZm/PYk1EiiHzN9uqLgncv4DaF16 al7euKxBW22f/t8YNEIqRnvXuUCx2ot3ISiDk+iT8rWM9umsMjsmvlPGFdFTotDZck +10D21HLClzfrVokN11LIOOYN3rfGElma9o82POmum4YIWhhzRczsoNmBGLNacCXn2 uwuWf6pEMqlWkGL7zZMjrEq5oNhJ0MRD1s9OcD5janaYD6mEAyLHxK7s/+mJPi9UEs 6lccM3GpyHNTr/MeUjRWNEdh6LsCBbCGyGv2QHmOkeedrTPttQkEdIsouc6ufVUd8c OECjHQVszQ0IY/QyDOjvQrk4= Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-c89704da8c7so1142328a12.0 for ; Thu, 23 Jul 2026 08:01:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784818877; x=1785423677; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rmn4iCRgd2W2Q1p9YGZBP63yr2RQlfKU8yIifwUIXo8=; b=TW4po+e9qAvLcCEiCmOhueWAUJUfaVSv4Ih96zpdGynsgs+ooB2WG8kzDfLEN6gNa4 2GGuH2rDeyG94KymzVmOL35XZVyEIrP7VcWlXG9EDbZ7wdSqgM8bmjyZJM/voAVH+7Jp mewoPBGNTtgLZM7zsdHWjLAk4GI8AX9IIEM1XESQfe5TSyN2gdtoZk6UET7WRz+NBC18 wAiVqqfFNyoDtqTBKmUvG6qVmER3mZbG7oztcfdmJFDu4fUBhyyUsYFH77bzrhEXTSo7 quO4sjtV8Kp6p7RnAbxNhkP1KxEyHXTPI2hP5wi296q0g2zqJE+9YX4osLLj4iGJAvNQ /SKQ== X-Forwarded-Encrypted: i=1; AHgh+RpiOPJ+rFDDZD699R/84SkQXZ7fUG9TxWgO3Oiv4kLzd7PXZlAwpdvMl3IX4pmLtv8Gug9eJo+hJp0CZv0=@vger.kernel.org X-Gm-Message-State: AOJu0Yyt96WkLGG09CFz0RwLIXdwDh1+FvpdCAVoobZAxphEgrCBU+06 1KBrMjVYmizYRK8ByLTA6IMAQ9xwaiz7Ms4WAJxhpxjhoahv2sCzR4SaMWy70inDVEylPqiMb9O Saq0Rd7ZuDLbpSb+gyG0cgihxOxkW0IVokoeiFeMm0sHTmTkINmz+I/aR+AFzMbfBpyXw5gUQ2P f43vKhmg== X-Gm-Gg: AR+sD12jpKxFYe701HyuiMm78Sb2/eShDSAxlIk6sHeXjnFk1qWJ2gKygDXwzn9AIih EFqgZIyoAH3KR+u3M1yokRGGasmbrQRG5rLXmo+5l5fL6CD4HMPI11Cl1hRhkvTytvpJjgQ4/8E mB+tOI+7D0yaMnaw7L7fRSevmQazYuMyQlUQr5cJtcHgaHG2UNXClMAo1DNJ7VAV79BX3Se2jGa o6q8hbeiPDcJq0+qsQ223/k7VQUDoEJpj77OcM5c/iwF/4530l+4aM6d1QnLL3wRAkAod5SeiBr zScy6U07DyjZzr17DDkgEb5FvUp8WFFw0cSeXPCUPVoOPUrMbQCzfjl/aUUwPvTS4Z4MOkpdZ6V fPDvDJrvYCOw= X-Received: by 2002:a17:90b:184c:b0:38e:8021:2ea9 with SMTP id 98e67ed59e1d1-38ec652455cmr4000005a91.19.1784818875930; Thu, 23 Jul 2026 08:01:15 -0700 (PDT) X-Received: by 2002:a17:90b:184c:b0:38e:8021:2ea9 with SMTP id 98e67ed59e1d1-38ec652455cmr3999946a91.19.1784818875309; Thu, 23 Jul 2026 08:01:15 -0700 (PDT) Received: from ZBook.gateway ([123.208.39.53]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13d12f267fdsm17077445c88.0.2026.07.23.08.01.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 08:01:14 -0700 (PDT) From: Changwei Zou To: herbert@gondor.apana.org.au, lukas@wunner.de, ignat@linux.win Cc: changwei.zou@canonical.com, davem@davemloft.net, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] crypto: rsassa-pkcs1: fix in-place DMA aliasing in rsassa_pkcs1_verify() Date: Fri, 24 Jul 2026 01:01:07 +1000 Message-ID: <20260723150107.33546-1-changwei.zou@canonical.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rsassa_pkcs1_verify() passes the same scatterlist as both src and dst to akcipher_request_set_crypt(): sg_init_one(&sg, out_buf, slen); akcipher_request_set_crypt(child_req, &sg, &sg, slen, slen); This causes the underlying hardware driver to DMA-map the same physical buffer twice with incompatible directions (DMA_TO_DEVICE and DMA_FROM_DEVICE), which is undefined behaviour on non-coherent architectures and leads to intermittent cache-coherency failures. dma_map_sg(dev, fixup_src, src_nents, DMA_TO_DEVICE); dma_map_sg(dev, req->dst, dst_nents, DMA_FROM_DEVICE); On non-coherent ARM64 platforms (e.g. i.MX8 with CAAM), the DMA_FROM_DEVICE mapping invalidates CPU cache lines covering the buffer after the DMA_TO_DEVICE mapping has flushed them but before the hardware reads the data. This produces a race that intermittently corrupts the RSA input, causing the EMSA-PKCS1-v1_5 structure check or digest comparison to fail with -EKEYREJECTED. Fix by allocating separate input and output buffers so each DMA mapping covers a distinct physical region, matching the approach used by the predecessor pkcs1pad template. The intermittent error 'Key was rejected by service' on i.MX8 with CAAM can be triggered when running the command below. for i in $(seq 1 100); do sudo modprobe xfs 2>&1 && echo "SUCCESS on attempt $i" \ && sudo rmmod xfs || echo "FAILED on attempt $i" done Fixes: 8552cb04e083 ("crypto: rsassa-pkcs1 - Copy source data for SG list") Signed-off-by: Changwei Zou --- crypto/rsassa-pkcs1.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/crypto/rsassa-pkcs1.c b/crypto/rsassa-pkcs1.c index 94fa5e9600e7..63bce31ac446 100644 --- a/crypto/rsassa-pkcs1.c +++ b/crypto/rsassa-pkcs1.c @@ -224,10 +224,10 @@ static int rsassa_pkcs1_verify(struct crypto_sig *tfm, unsigned int child_reqsize =3D crypto_akcipher_reqsize(ctx->child); struct akcipher_request *child_req __free(kfree_sensitive) =3D NULL; struct crypto_wait cwait; - struct scatterlist sg; + struct scatterlist sg_src, sg_dst; unsigned int dst_len; unsigned int pos; - u8 *out_buf; + u8 *in_buf, *out_buf; int err; =20 /* RFC 8017 sec 8.2.2 step 1 - length checking */ @@ -236,19 +236,30 @@ static int rsassa_pkcs1_verify(struct crypto_sig *tfm, rsassa_pkcs1_invalid_hash_len(dlen, hash_prefix)) return -EINVAL; =20 - /* RFC 8017 sec 8.2.2 step 2 - RSA verification */ - child_req =3D kmalloc(sizeof(*child_req) + child_reqsize + ctx->key_size, - GFP_KERNEL); + /* + * RFC 8017 sec 8.2.2 step 2 - RSA verification + * + * Allocate separate input and output buffers within the child_req + * allocation. Using the same buffer for both src and dst (in-place) + * would cause it to be DMA-mapped twice with incompatible directions + * (DMA_TO_DEVICE and DMA_FROM_DEVICE), which is undefined behaviour on + * non-coherent architectures such as ARM64 with hardware accelerators + * like CAAM, leading to intermittent cache-coherency failures. + */ + child_req =3D kmalloc(sizeof(*child_req) + child_reqsize + + 2 * ctx->key_size, GFP_KERNEL); if (!child_req) return -ENOMEM; =20 - out_buf =3D (u8 *)(child_req + 1) + child_reqsize; - memcpy(out_buf, src, slen); + in_buf =3D (u8 *)(child_req + 1) + child_reqsize; + out_buf =3D in_buf + ctx->key_size; + memcpy(in_buf, src, slen); =20 crypto_init_wait(&cwait); - sg_init_one(&sg, out_buf, slen); + sg_init_one(&sg_src, in_buf, slen); + sg_init_one(&sg_dst, out_buf, slen); akcipher_request_set_tfm(child_req, ctx->child); - akcipher_request_set_crypt(child_req, &sg, &sg, slen, slen); + akcipher_request_set_crypt(child_req, &sg_src, &sg_dst, slen, slen); akcipher_request_set_callback(child_req, CRYPTO_TFM_REQ_MAY_SLEEP, crypto_req_done, &cwait); =20 --=20 2.43.0