Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp5424269ybf; Thu, 5 Mar 2020 00:23:23 -0800 (PST) X-Google-Smtp-Source: ADFU+vvbLy76IaGIr91fEu+PMPgBJEbgaILNJvsN1h3GhmhZAy07HA5geQ62dqepEel4+h5rq3Df X-Received: by 2002:aca:4b47:: with SMTP id y68mr4964682oia.38.1583396603684; Thu, 05 Mar 2020 00:23:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583396603; cv=none; d=google.com; s=arc-20160816; b=kxzA1wmLctKorEPcQbmOYcDzbGoHUbpHoQZhwOlgYjfrOA51FfljUQR3a1dSObA+rx npRidqVxexvDe3J3QpSP4Igi5KduU3I94poI2w/zgYy5elBo5HSKAN4SrKxNxYcJWC1B k5xHJ5wPEGesJM2rpNx1mb2+J7CrW/tRIel4rvVx0TZqqXM3QwhXj98+SilTKSQdB1r1 dDv1a9fSLZ/MdFHQI6p1nadeh5VYwndt5WxlUazbLsaFlpQwb6S9ITbUnUoIJrvIjUgr hqTcncqaHk6otqLlBcwnWvp/geS83SDGEGeST2fKR7/ssbS2M8f6QtRMBOzjj1pzWfpD s8sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=Pwg1CgJEQdAnnSIgCSwnzI9Kw9d5CYwA10lUqtN1xfk=; b=aNq3o8v9c0ns94lxvBPEJG9wDf8w+5Zpf7UqeNpCz+M1VCUCGAZ0ocV/MXN2m/I9PK 52TvXWLanoIqPXQtUlXQ1p8ffIKHtegEf+qWseTC+/riugaUpzjpkfOGEL0ibTnmxsYc O4Tt8MoG2UgX2ayRivGgN11JSjBJY9PTh5U5j//rQ0p2r2hOL8W5YzaLpyaPb7VD+Bbo OJrO44SKkEbfqJvK4soQkDeJldcC/VvgRbTblzcoTj08g/0AaGeJYEPJv+3lRdPnw9xq kOLRduqoJFEw/uhLd9nATt4rt1/lqZUCpZobQU1+f8ZSezgY56kY7F5F5U/4n8Cwu7tE KPSg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x10si2786782oic.136.2020.03.05.00.23.04; Thu, 05 Mar 2020 00:23:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725944AbgCEIWU (ORCPT + 99 others); Thu, 5 Mar 2020 03:22:20 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11148 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725816AbgCEIWU (ORCPT ); Thu, 5 Mar 2020 03:22:20 -0500 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id DAD5F85F05C65E426F96; Thu, 5 Mar 2020 16:22:12 +0800 (CST) Received: from fedora-aep.huawei.cmm (10.175.113.49) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.439.0; Thu, 5 Mar 2020 16:22:07 +0800 From: yangerkun To: , CC: , Subject: [PATCH 4.4.y] crypto: algif_skcipher - use ZERO_OR_NULL_PTR in skcipher_recvmsg_async Date: Thu, 5 Mar 2020 16:50:10 +0800 Message-ID: <20200305085010.21324-1-yangerkun@huawei.com> X-Mailer: git-send-email 2.17.2 MIME-Version: 1.0 Content-Type: text/plain 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 ... [] do_async_page_fault+0x37/0xb0 x86/../arch/x86/kernel/kvm.c:266 [] async_page_fault+0x28/0x30 x86/../arch/x86/entry/entry_64.S:1043 [] iov_iter_zero+0x15a/0x850 x86/../lib/iov_iter.c:445 [] read_iter_zero+0xcf/0x1b0 x86/../drivers/char/mem.c:708 [] do_iter_readv_writev x86/../fs/read_write.c:679 [inline] [] do_readv_writev+0x448/0x8e0 x86/../fs/read_write.c:823 [] vfs_readv+0x7f/0xb0 x86/../fs/read_write.c:849 [] SYSC_preadv x86/../fs/read_write.c:927 [inline] [] SyS_preadv+0x193/0x240 x86/../fs/read_write.c:913 [] entry_SYSCALL_64_fastpath+0x1e/0x9a 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(-) 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); -- 2.17.2