Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp5424266ybf; Thu, 5 Mar 2020 00:23:23 -0800 (PST) X-Google-Smtp-Source: ADFU+vvVFlwxBb8DvYTy1uQTJKLbvEjt/HcNNrwlMxkgfu96nfOV8uUEABnblyLnFYqvyAoJTFbK X-Received: by 2002:aca:cdd1:: with SMTP id d200mr4572002oig.153.1583396603685; 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=pceUahLY/szZMgTkK7xxp9KH8p7LK9yFY93CDsnoqvYzms+CVo5kR4UN679IMW+aGW NJhUrt5U+BzIKYuRltqJXPeRBe4qRW0hE1D/b8r/Ba/XO8iJ0A0+ZyBD3j58b1dQhVTq 58tQo3eCWOnDmOn+DNYZDsotQaaGUB3n7tcvyiWu/0GS9+k0AYk0hw5VM5D3ofwUJwDn BBn3mjpHTsMQoA2FeqU+Aw2i4jQ7t75h5CMaFfaqWQg/IoZFlENQcEIEyPBjWIWCjr+z oCAAX1rv1pyU4rLeIYdViFczk3gAm8wa+iOtohCb1xGfUPDdWIF00rzUAFsrG6YFh/Uf neZg== 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=pq5lCEBqp6bxO8DrDcFVEYjA9ikqhTS/D7xVsdshWo50j0YkuoZ1yMTE5/4dB1aaiu +kPVJx0GvNbb5W1NVU5rliJ3+v4Qtndjs/h14s5cpAu4ZNOJAGXjxt5PEeYHrM8N+SZX S7w7D3yKXUdjknzYZfzpXpexbXoMJA/rRt7ZkJ1JjYu7qeMXI5EBy8mZpO80jTFbTgvk +96s/KDvIsAw7rjaRXbTC/8Q3Y+1hgruZ4V81iu560z1KHMu0+juUCOg6FjRc1tOHjHr XGlZ3Jn25gmVj4LsVPJFewiy4MrUn+MZXbQAFxYN1NwmqoGjtfQuc5doDQH9sZd/EszS cHRw== 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 a59si3059780otb.8.2020.03.05.00.23.06; 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 S1725912AbgCEIWu (ORCPT + 99 others); Thu, 5 Mar 2020 03:22:50 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:38530 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725816AbgCEIWu (ORCPT ); Thu, 5 Mar 2020 03:22:50 -0500 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 2A51EF1B93CA484CD08B; Thu, 5 Mar 2020 16:22:45 +0800 (CST) Received: from fedora-aep.huawei.cmm (10.175.113.49) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.439.0; Thu, 5 Mar 2020 16:22:36 +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:40 +0800 Message-ID: <20200305085040.21551-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