Message ID | 20231211135949.689204-1-syoshida@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp7068782vqy; Mon, 11 Dec 2023 06:03:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IHmzGfoqnTza76dpD9iktL/uJUEEoFy1cVPNcj3oww5to08eO40cTS1ZFKs2ZUa5Kpk5QTi X-Received: by 2002:a62:e414:0:b0:6ce:2731:e873 with SMTP id r20-20020a62e414000000b006ce2731e873mr4218721pfh.58.1702303397548; Mon, 11 Dec 2023 06:03:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702303397; cv=none; d=google.com; s=arc-20160816; b=tRTF9mDEKuGmQHASHwZ2aFuLoPFcH+LS1Drh+7ChNUrBv5md8GRYknrrwx/Xdm8tcM HDeesk3SJasQfXiLZbjqm4w8hL5S7nVDPUnLn+LdAbahL6rrcPLkMcB065w4SWnotVoh V3aOhe26iKn6rL922PFoiF4QRfGVfBUVBEIoTPc7r2jLE+OwnSVCP99qmcid9vjkKUe0 jNvUYlCRv3nJ5Jsgu7sOPPy9ZHeMW+mmVqSCl7wnVOEpHQOSbOWM9NU5iC7lfAHKVFHy 03rdKpK5rO61zm6uM+4XSDATBryhh44Z+r8F1lO+fFYpU3ekQlAO+dzLmkjpGJB0LG3r +1lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=jNtOY4LpZQRmFFwaKjy6gBWig0U9E1fsIgKhcHzr1a8=; fh=kOAkKf5TvF2uvlRMSmt2LKYDRqGs0lqW3VdJ+OsUjtQ=; b=XJgW2tptB1V1aI7rE7d+uMZPPXcfSFT0IG3WbBf9y/VZ8JWzPOLogkRUCm6/7blhLm w5fdE3XGIi9duuS9Tjt1De0MuzHy+QKpv/lSh/S34vC7+HZDQBJmdceFOvfH0+mmlJ6s u0l0fCoceYYLp5yF7cM+QTFtaRW/jUxVJOrj2KrshVIZurxUwVlOeTql0aoalR82yZZJ Hnit3JeGYixsQ4y7RSPvhRiyz5pOfSavvF9YqjslXHb5urkGEuC/sG5LJpZUzymRpxa3 9PGCKsEqoYxlFtT1oSIeN0VQvMvvadtmA5DI1Y6PSAOpXxY/8xdksuNPj+JYnafLecAr +Rzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JLUZYGk0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id j3-20020a056a00174300b006cd852a8a83si6275432pfc.147.2023.12.11.06.03.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 06:03:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JLUZYGk0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id E3E92803F8DF; Mon, 11 Dec 2023 06:03:05 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344021AbjLKOCo (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Mon, 11 Dec 2023 09:02:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343950AbjLKOCY (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 11 Dec 2023 09:02:24 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57A8E47AD for <linux-kernel@vger.kernel.org>; Mon, 11 Dec 2023 06:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702303199; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=jNtOY4LpZQRmFFwaKjy6gBWig0U9E1fsIgKhcHzr1a8=; b=JLUZYGk0tqtYaPJ5kVPbIjFzzfHonixcfZP0yrCmCO8K54K7BensbDTstb4FMgU/QszSQl /8X1w74FjmOe5EtlzRd6cR/rfBZxCVy5YanV436wY2/bYOmH5eS0AabyG8IMwtErBLPA9W 28YNXI2TBVfL9DRSk535gQnFpk827iE= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-499-_PvnCrkVPaSjqHyG2M3OuQ-1; Mon, 11 Dec 2023 08:59:58 -0500 X-MC-Unique: _PvnCrkVPaSjqHyG2M3OuQ-1 Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-6ce6fa748c5so5309531b3a.3 for <linux-kernel@vger.kernel.org>; Mon, 11 Dec 2023 05:59:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702303197; x=1702907997; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jNtOY4LpZQRmFFwaKjy6gBWig0U9E1fsIgKhcHzr1a8=; b=k+pCe8xC+zQRzGgkIDlb/pWlZXxMEAKL5IsqEoxbvR2FREcbCNyZg/wC/1oscunJpe cuvxLSOihnnhOHTaYuSBS19y8h+iFASTDPCWXwAkz9D0p0qirQprmw0i2y8hdO7uqwf8 5ZXXqXuCWeGXUkYBGGg7aH+/dosNwBmJUBVrnfWxf5vQJsMn94EQSM/X71S7w8o8kRnL UI6bxwQ2DzutxiVTrqMuJXxZVOII/LSXOHa8p0uJuHcDb5R6uLRhODLi3tWRMvf4SxFp Nl5dUTLjq1N1apMzWlMqM29uE6SlzR23EPaqkquzfm3le77mJSId/ZZPw5ZFbRVbiyHu YYFA== X-Gm-Message-State: AOJu0Yye3ooGUw3iuRhgQ/4qyJIWkz+fyY8CMobJvxYTfCgGiBaeLG64 uWM5uqLHSWdXpZFJIEQlY1fwqlkWnPFSph32P3+ZZrXKIVGFhqRnpbgmADq/UIWExhXfejvyYjs qTMF3R9eCxtxkDHax8tZOmmAsC2TPyfKA X-Received: by 2002:a05:6a00:4b05:b0:6cd:8a19:c324 with SMTP id kq5-20020a056a004b0500b006cd8a19c324mr5065046pfb.3.1702303196832; Mon, 11 Dec 2023 05:59:56 -0800 (PST) X-Received: by 2002:a05:6a00:4b05:b0:6cd:8a19:c324 with SMTP id kq5-20020a056a004b0500b006cd8a19c324mr5065039pfb.3.1702303196506; Mon, 11 Dec 2023 05:59:56 -0800 (PST) Received: from kernel-devel.local ([240d:1a:c0d:9f00:245e:16ff:fe87:c960]) by smtp.gmail.com with ESMTPSA id ei43-20020a056a0080eb00b006ce6e431292sm6280383pfb.38.2023.12.11.05.59.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 05:59:56 -0800 (PST) From: Shigeru Yoshida <syoshida@redhat.com> To: herbert@gondor.apana.org.au, davem@davemloft.net Cc: dhowells@redhat.com, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Shigeru Yoshida <syoshida@redhat.com> Subject: [PATCH] crypto: af_alg/hash: Fix uninit-value access in af_alg_free_sg() Date: Mon, 11 Dec 2023 22:59:49 +0900 Message-ID: <20231211135949.689204-1-syoshida@redhat.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Mon, 11 Dec 2023 06:03:06 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784994487689487863 X-GMAIL-MSGID: 1784994487689487863 |
Series |
crypto: af_alg/hash: Fix uninit-value access in af_alg_free_sg()
|
|
Commit Message
Shigeru Yoshida
Dec. 11, 2023, 1:59 p.m. UTC
KMSAN reported the following uninit-value access issue:
=====================================================
BUG: KMSAN: uninit-value in af_alg_free_sg+0x1c1/0x270 crypto/af_alg.c:547
af_alg_free_sg+0x1c1/0x270 crypto/af_alg.c:547
hash_sendmsg+0x188f/0x1ce0 crypto/algif_hash.c:172
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x997/0xd60 net/socket.c:2584
___sys_sendmsg+0x271/0x3b0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x2fa/0x4a0 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x103/0x9e0 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5d5/0x9b0 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc+0x118/0x410 mm/slab_common.c:1020
kmalloc include/linux/slab.h:604 [inline]
sock_kmalloc+0x104/0x1a0 net/core/sock.c:2681
hash_accept_parent_nokey crypto/algif_hash.c:418 [inline]
hash_accept_parent+0xbc/0x470 crypto/algif_hash.c:445
af_alg_accept+0x1d8/0x810 crypto/af_alg.c:439
hash_accept+0x368/0x800 crypto/algif_hash.c:254
do_accept+0x803/0xa70 net/socket.c:1927
__sys_accept4_file net/socket.c:1967 [inline]
__sys_accept4+0x170/0x340 net/socket.c:1997
__do_sys_accept4 net/socket.c:2008 [inline]
__se_sys_accept4 net/socket.c:2005 [inline]
__x64_sys_accept4+0xc0/0x150 net/socket.c:2005
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 14168 Comm: syz-executor.2 Not tainted 6.7.0-rc4-00009-gbee0e7762ad2 #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014
=====================================================
In hash_sendmsg(), hash_alloc_result() may fail and return -ENOMEM if
sock_kmalloc() fails. In this case, hash_sendmsg() jumps to the unlock_free
label and calls af_alg_free_sg() with ctx->sgl.sgt.sgl uninitialized. This
causes the above uninit-value access issue for ctx->sgl.sgt.sgl.
This patch fixes this issue by initializing ctx->sgl.sgt.sgl when the
structure is allocated in hash_accept_parent_nokey().
Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES")
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
---
crypto/algif_hash.c | 1 +
1 file changed, 1 insertion(+)
Comments
On Mon, Dec 11, 2023 at 10:59:49PM +0900, Shigeru Yoshida wrote: > > Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") I think it should actually be b6d972f6898308fbe7e693bf8d44ebfdb1cd2dc4 crypto: af_alg/hash: Fix recvmsg() after sendmsg(MSG_MORE) Anyway, I think we should fix it by adding a new goto label that does not free the SG list: unlock_free: af_alg_free_sg(&ctx->sgl); <--- Add new label here hash_free_result(sk, ctx); ctx->more = false; goto unlock; Thanks,
On Fri, 22 Dec 2023 11:42:43 +0800, Herbert Xu wrote: > On Mon, Dec 11, 2023 at 10:59:49PM +0900, Shigeru Yoshida wrote: >> >> Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") > > I think it should actually be > > b6d972f6898308fbe7e693bf8d44ebfdb1cd2dc4 > crypto: af_alg/hash: Fix recvmsg() after sendmsg(MSG_MORE) > > Anyway, I think we should fix it by adding a new goto label that > does not free the SG list: > > unlock_free: > af_alg_free_sg(&ctx->sgl); > <--- Add new label here > hash_free_result(sk, ctx); > ctx->more = false; > goto unlock; Thanks for the feedback, and sorry for the late response. I'll check the code again, and send v2 patch. Thanks, Shigeru > > Thanks, > -- > Email: Herbert Xu <herbert@gondor.apana.org.au> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt >
Herbert Xu <herbert@gondor.apana.org.au> wrote: > Anyway, I think we should fix it by adding a new goto label that > does not free the SG list: > > unlock_free: > af_alg_free_sg(&ctx->sgl); > <--- Add new label here > hash_free_result(sk, ctx); > ctx->more = false; > goto unlock; Hmmm... Is that going to get you a potential memory leak? ctx->sgl.sgt.sgl could (in theory) point to an allocated table. I guess that would be cleaned up by af_alg_free_areq_sgls(), so there's probably no leak there. OTOH, af_alg_free_areq_sgls() is going to call af_alg_free_sg(), so maybe we want to initialise sgl->sgt.sgl to NULL as well. Does it make sense just to clear *ctx entirely in hash_accept_parent_nokey()? David
On Wed, Jan 03, 2024 at 03:36:51PM +0000, David Howells wrote: > Hmmm... Is that going to get you a potential memory leak? > > ctx->sgl.sgt.sgl could (in theory) point to an allocated table. I guess that > would be cleaned up by af_alg_free_areq_sgls(), so there's probably no leak > there. The SG list is only setup in this function, and gets freed before we return. There should be no SG list on entry. It's only because you added the special case for a zero-length hash that we hit the bogus free. So we should fix this by not freeing the SG list in the zero-length case, as it was never allocated. > OTOH, af_alg_free_areq_sgls() is going to call af_alg_free_sg(), so maybe we > want to initialise sgl->sgt.sgl to NULL as well. That has nothing to do with this. This SG list is specific to algif_hash and has nothing to do with the shared SG list used by aead and skcipher. Cheers,
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c index 82c44d4899b9..a51b58d36d60 100644 --- a/crypto/algif_hash.c +++ b/crypto/algif_hash.c @@ -419,6 +419,7 @@ static int hash_accept_parent_nokey(void *private, struct sock *sk) if (!ctx) return -ENOMEM; + ctx->sgl.sgt.sgl = NULL; ctx->result = NULL; ctx->len = len; ctx->more = false;