From patchwork Thu Mar 5 08:57:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: yangerkun X-Patchwork-Id: 198011 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E5D5C3F2D7 for ; Thu, 5 Mar 2020 08:30:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 360AF2166E for ; Thu, 5 Mar 2020 08:30:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725924AbgCEIaB (ORCPT ); Thu, 5 Mar 2020 03:30:01 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:11169 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725880AbgCEIaB (ORCPT ); Thu, 5 Mar 2020 03:30:01 -0500 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id C618C65B5E46CE54B206; Thu, 5 Mar 2020 16:29:58 +0800 (CST) Received: from fedora-aep.huawei.cmm (10.175.113.49) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.439.0; Thu, 5 Mar 2020 16:29:50 +0800 From: yangerkun To: , CC: , , Subject: [PATCH 4.4.y v2] crypto: algif_skcipher - use ZERO_OR_NULL_PTR in skcipher_recvmsg_async Date: Thu, 5 Mar 2020 16:57:55 +0800 Message-ID: <20200305085755.22730-1-yangerkun@huawei.com> X-Mailer: git-send-email 2.17.2 MIME-Version: 1.0 X-Originating-IP: [10.175.113.49] X-CFilter-Loop: Reflected Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Nowdays, we trigger a oops: ... kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] SMP KASAN ... Call Trace: [] skcipher_recvmsg_async+0x3f1/0x1400 x86/../crypto/algif_skcipher.c:543 [] skcipher_recvmsg+0x93/0x7f0 x86/../crypto/algif_skcipher.c:723 [] sock_recvmsg_nosec x86/../net/socket.c:702 [inline] [] sock_recvmsg x86/../net/socket.c:710 [inline] [] sock_recvmsg+0x94/0xc0 x86/../net/socket.c:705 [] sock_read_iter+0x27b/0x3a0 x86/../net/socket.c:787 [] aio_run_iocb+0x21b/0x7a0 x86/../fs/aio.c:1520 [] io_submit_one x86/../fs/aio.c:1630 [inline] [] do_io_submit+0x6b9/0x10b0 x86/../fs/aio.c:1688 [] SYSC_io_submit x86/../fs/aio.c:1713 [inline] [] SyS_io_submit+0x2d/0x40 x86/../fs/aio.c:1710 [] tracesys_phase2+0x90/0x95 In skcipher_recvmsg_async, we use '!sreq->tsg' to determine does we calloc fail. However, kcalloc may return ZERO_SIZE_PTR, and with this, the latter sg_init_table will trigger the bug. Fix it be use ZERO_OF_NULL_PTR. This function was introduced with ' commit a596999b7ddf ("crypto: algif - change algif_skcipher to be asynchronous")', and has been removed with 'commit e870456d8e7c ("crypto: algif_skcipher - overhaul memory management")'. Reported-by: Hulk Robot Signed-off-by: yangerkun --- crypto/algif_skcipher.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) v1->v2: update the commit message diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c index d12782dc9683..9bd4691cc5c5 100644 --- a/crypto/algif_skcipher.c +++ b/crypto/algif_skcipher.c @@ -538,7 +538,7 @@ static int skcipher_recvmsg_async(struct socket *sock, struct msghdr *msg, lock_sock(sk); tx_nents = skcipher_all_sg_nents(ctx); sreq->tsg = kcalloc(tx_nents, sizeof(*sg), GFP_KERNEL); - if (unlikely(!sreq->tsg)) + if (unlikely(ZERO_OR_NULL_PTR(sreq->tsg))) goto unlock; sg_init_table(sreq->tsg, tx_nents); memcpy(iv, ctx->iv, ivsize);