From nobody Wed Jun 17 06:05:38 2026 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8670D364036 for ; Thu, 23 Apr 2026 11:20:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776943225; cv=none; b=EeBVFwFRYa4ck7zSFlaCIB43XmuzHAdJyUN/OrTeAxlc2rWzhdSeM+pd+By9wtir16KtnZCtSgCQbAoove2XTk5ksuTUsQJxCNzM/XEJFLF0CIRZqEbowt7OHiKmhKY80E2nyR12j3xcTha30yl/w6HhNcK8i1QDkyskbKrL43k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776943225; c=relaxed/simple; bh=+1XyvQRM0gBy3IMiyOE5RaAvDDzH4OZ8Vq8cH5BT8oE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=uvE+c7tZ25VwkXh+q0aA3Irer5yhLfpf9TQdxEjfYcCFrzUxmr1lBDlv/LjRiBO6XCmURLoXXvez6d/79SaLTUVuHbEra5HOF7S8ynUmQZz3gJWrLQb0OiN9bm7SZ0JC3B5hZGB1rCnXjBSkdT962QfFWjcpRm4a8C5nhyXp1pU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SxfgClJ+; arc=none smtp.client-ip=209.85.216.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SxfgClJ+" Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-35da2d35eccso4566005a91.0 for ; Thu, 23 Apr 2026 04:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776943224; x=1777548024; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=RwuJIm7Dw5jp31ncEc1KOiDX7dt/dDt8uIoQj49sz9E=; b=SxfgClJ+nu4PknWA/9Eycduk3SeUPlDKY/JUdeB0h45Gf2FHMEW7v7TlV9oVjIZSr7 AufSlZvVU61Ls1wOzAwZzghtifHBji7volmd99HL+7AUMl6l65fTahmrl9dp0uI9sl5q 5nh74crUhWSHCvG6QqCIfxUSOSgYhabY6XKmcnrQuJ3Ml5J1AGSkO7KGSLqCVHSBlpj2 LNMpS3m1qKs/bxDxZbTRGwJ8iXa2edVLQPKeA76+FKtfoCw9zMJmmb6r96R082N5CAZu yD3ZGZFSfEgG01NIkXCUWcN1/J5c5XqXIda+uw5zZom0mYbQZqOWjHKOIWkG7gqT/n3Q XAIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776943224; x=1777548024; 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; bh=RwuJIm7Dw5jp31ncEc1KOiDX7dt/dDt8uIoQj49sz9E=; b=YVdOs5ZgBMFX22GUs5DZHriZ4hfyt76omG0zRh+66/sOv6yGwLje/VEDPNwFIWxYVh AGCkGpk9bc49cydjbYEXIu5H11s+WX7O8kOdbWL1B1VaMcQk0NeYV04cNq/OdpKWhtt9 a65VZDHq1I/F9dtRXwDmMwaASMUE8nZWyDkUlRDy1hV4aVZE8+Kl5pagavVkPOfFGNJY BS7VaXlLoprFGDgVqzDkfVJJNOrHsVe7VbHcPpasWzgRAjkTUuALPNUEGRH/nACHo5H5 3fJ3H2VryabwL/CW0ptwXM1o8hNWQAcOXQdk86XFimf8Q3nKqmnOcF1ILm8fJQDLrvh2 DvQg== X-Forwarded-Encrypted: i=1; AFNElJ9LFdvMjdy04aKuGOspmf06yNeNHKTbxntaFoT7FM03v+oTqO5a6duhskWvM/O8oH7cLndetMIOoDM8kqw=@vger.kernel.org X-Gm-Message-State: AOJu0Yyou4BvBbGnATWPCeGgh3Gpc0v48zsTQ0orbFgtI8fj8FNvMIJE VzFf63g/DLcBXUDd8O446atxlCCTXDJn2LiBWM8ykZ8CLJGoZ3rS4+nv X-Gm-Gg: AeBDietBXb/jFcjp7u20Pyn5FKhplfg9M54Bkk6CNsZNj8g6mELkNGcLyb6pv+HtpwL MREIFtUjLQnWrHiNsDEARo82Av1Y0BUU1ZsUAAq+5D7at6XG7vkgekgUnsK5N1DEPYyNW+IlD+U bCrEEWuZMmChJ7Tig17MTJmRJDxwEI50cvdZc3JFHGPrJw3K5/3cz/UlRl7uEUqhwulQ/dHEdU+ 6pukFe9BUP8f5YNoaLre6+LWGgq/wOm2CgSKD27WbGnxASA8r+OrvbRk7xQpgjYkiao/5CRpref GNlhArPti9UeRCnjykBo8F+oeu0Gsnpitv45BDYZWCEd53DAowqyuv0foFNWFnUEIaoH2pw6Q4V jdteEVG1xo8VAAKVcCgTKVAOJ5fVqlQ3QjML4Mt9GwzJG047Hi2hTtPY1lUWdfuALv308vG3Pn8 vg+3CalxKZ8dCWFvKiquU+1BzB3joO1G+glzMwimvSnRh1zsUPL40bubGJqe0LCeU= X-Received: by 2002:a17:90b:2243:b0:35f:bf4b:c396 with SMTP id 98e67ed59e1d1-361403ca5femr25738150a91.1.1776943223737; Thu, 23 Apr 2026 04:20:23 -0700 (PDT) Received: from LAPTOP-CUCB24GH.tail9a93e7.ts.net ([175.159.176.252]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36141973c57sm19456388a91.14.2026.04.23.04.20.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 04:20:23 -0700 (PDT) From: Ruoyu Wang To: Herbert Xu , Corentin Labbe , linux-crypto@vger.kernel.org Cc: Linus Walleij , Imre Kaloz , "David S . Miller" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Ruoyu Wang Subject: [PATCH v2] crypto: ixp4xx - fix buffer chain unwind on allocation failure Date: Thu, 23 Apr 2026 19:19:56 +0800 Message-ID: <20260423111956.185761-1-ruoyuw560@gmail.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" chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next =3D NULL; buf->phys_next =3D 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly. Signed-off-by: Ruoyu Wang Acked-by: Linus Walleij --- v2: - Keep the unwind path in the callers, per Herbert Xu's feedback. - Terminate the partial chain before returning NULL on allocation failure. - Save the hook pointers in ablk_perform() before checking the return value. - Thanks to Herbert Xu for the review. drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c | 25 ++++++++++++--------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c b/drivers/crypto/i= ntel/ixp4xx/ixp4xx_crypto.c index fcc0cf4df..5b90cf0fb 100644 --- a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c +++ b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c @@ -884,8 +884,9 @@ static struct buffer_desc *chainup_buffers(struct devic= e *dev, ptr =3D sg_virt(sg); next_buf =3D dma_pool_alloc(buffer_pool, flags, &next_buf_phys); if (!next_buf) { - buf =3D NULL; - break; + buf->next =3D NULL; + buf->phys_next =3D 0; + return NULL; } sg_dma_address(sg) =3D dma_map_single(dev, ptr, len, dir); buf->next =3D next_buf; @@ -983,7 +984,7 @@ static int ablk_perform(struct skcipher_request *req, i= nt encrypt) unsigned int nbytes =3D req->cryptlen; enum dma_data_direction src_direction =3D DMA_BIDIRECTIONAL; struct ablk_ctx *req_ctx =3D skcipher_request_ctx(req); - struct buffer_desc src_hook; + struct buffer_desc *buf, src_hook; struct device *dev =3D &pdev->dev; unsigned int offset; gfp_t flags =3D req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ? @@ -1025,22 +1026,24 @@ static int ablk_perform(struct skcipher_request *re= q, int encrypt) /* This was never tested by Intel * for more than one dst buffer, I think. */ req_ctx->dst =3D NULL; - if (!chainup_buffers(dev, req->dst, nbytes, &dst_hook, - flags, DMA_FROM_DEVICE)) - goto free_buf_dest; - src_direction =3D DMA_TO_DEVICE; + buf =3D chainup_buffers(dev, req->dst, nbytes, &dst_hook, + flags, DMA_FROM_DEVICE); req_ctx->dst =3D dst_hook.next; crypt->dst_buf =3D dst_hook.phys_next; + if (!buf) + goto free_buf_dest; + src_direction =3D DMA_TO_DEVICE; } else { req_ctx->dst =3D NULL; } req_ctx->src =3D NULL; - if (!chainup_buffers(dev, req->src, nbytes, &src_hook, flags, - src_direction)) - goto free_buf_src; - + buf =3D chainup_buffers(dev, req->src, nbytes, &src_hook, flags, + src_direction); req_ctx->src =3D src_hook.next; crypt->src_buf =3D src_hook.phys_next; + if (!buf) + goto free_buf_src; + crypt->ctl_flags |=3D CTL_FLAG_PERFORM_ABLK; qmgr_put_entry(send_qid, crypt_virt2phys(crypt)); BUG_ON(qmgr_stat_overflow(send_qid)); --=20 2.43.0