From mboxrd@z Thu Jan 1 00:00:00 1970 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 41048C0650F for ; Mon, 5 Aug 2019 13:07:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 170F42087B for ; Mon, 5 Aug 2019 13:07:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565010454; bh=z/iIGjQWhg+fNgqW19KPoU3voIdGwp4u3fqY7YfdqyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=mjB977vUZNZP9/fwupz2Q6i03eEW/6Jnk8vi1djixsr88WUaVQcBx3rE+zduXWR+F AcAKcFHFJuopWnMfS9n7pU/N84X2ptRy/+xv6KEkf5uOn2ggUlLazwSUtNZdEohhCV 0Muo+XdhCvaYMmIa/qWK2fu59ElwYnkqzL3B8f5E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729820AbfHENHc (ORCPT ); Mon, 5 Aug 2019 09:07:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:45024 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729264AbfHENH2 (ORCPT ); Mon, 5 Aug 2019 09:07:28 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8E9C82173B; Mon, 5 Aug 2019 13:07:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565010448; bh=z/iIGjQWhg+fNgqW19KPoU3voIdGwp4u3fqY7YfdqyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fxka1TnL3m2lKc8rEdkHZw8QIAMIxGFk7bQ15OjalnoxjP0BqUzn3QPoMsCYQlYIh /PiyWJzq9fYe8vg2W520klaQA6PFZHHYSNLfoHOT8YTFl6RrGRDFkqL4UwFyscRate ygY+tNK7VVEh4/VQ2OibtpiZ3p1uswJXDyWuJhk4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kees Cook , Andreas Christoforou , "Eric W. Biederman" , Al Viro , Arnd Bergmann , Davidlohr Bueso , Manfred Spraul , Andrew Morton , Linus Torvalds , Sasha Levin Subject: [PATCH 4.14 27/53] ipc/mqueue.c: only perform resource calculation if user valid Date: Mon, 5 Aug 2019 15:02:52 +0200 Message-Id: <20190805124931.057378053@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190805124927.973499541@linuxfoundation.org> References: <20190805124927.973499541@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Upstream commit a318f12ed8843cfac53198390c74a565c632f417 ] Andreas Christoforou reported: UBSAN: Undefined behaviour in ipc/mqueue.c:414:49 signed integer overflow: 9 * 2305843009213693951 cannot be represented in type 'long int' ... Call Trace: mqueue_evict_inode+0x8e7/0xa10 ipc/mqueue.c:414 evict+0x472/0x8c0 fs/inode.c:558 iput_final fs/inode.c:1547 [inline] iput+0x51d/0x8c0 fs/inode.c:1573 mqueue_get_inode+0x8eb/0x1070 ipc/mqueue.c:320 mqueue_create_attr+0x198/0x440 ipc/mqueue.c:459 vfs_mkobj+0x39e/0x580 fs/namei.c:2892 prepare_open ipc/mqueue.c:731 [inline] do_mq_open+0x6da/0x8e0 ipc/mqueue.c:771 Which could be triggered by: struct mq_attr attr = { .mq_flags = 0, .mq_maxmsg = 9, .mq_msgsize = 0x1fffffffffffffff, .mq_curmsgs = 0, }; if (mq_open("/testing", 0x40, 3, &attr) == (mqd_t) -1) perror("mq_open"); mqueue_get_inode() was correctly rejecting the giant mq_msgsize, and preparing to return -EINVAL. During the cleanup, it calls mqueue_evict_inode() which performed resource usage tracking math for updating "user", before checking if there was a valid "user" at all (which would indicate that the calculations would be sane). Instead, delay this check to after seeing a valid "user". The overflow was real, but the results went unused, so while the flaw is harmless, it's noisy for kernel fuzzers, so just fix it by moving the calculation under the non-NULL "user" where it actually gets used. Link: http://lkml.kernel.org/r/201906072207.ECB65450@keescook Signed-off-by: Kees Cook Reported-by: Andreas Christoforou Acked-by: "Eric W. Biederman" Cc: Al Viro Cc: Arnd Bergmann Cc: Davidlohr Bueso Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- ipc/mqueue.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/ipc/mqueue.c b/ipc/mqueue.c index 5c0ae912f2f25..dccd4ecb786ac 100644 --- a/ipc/mqueue.c +++ b/ipc/mqueue.c @@ -372,7 +372,6 @@ static void mqueue_evict_inode(struct inode *inode) { struct mqueue_inode_info *info; struct user_struct *user; - unsigned long mq_bytes, mq_treesize; struct ipc_namespace *ipc_ns; struct msg_msg *msg, *nmsg; LIST_HEAD(tmp_msg); @@ -395,16 +394,18 @@ static void mqueue_evict_inode(struct inode *inode) free_msg(msg); } - /* Total amount of bytes accounted for the mqueue */ - mq_treesize = info->attr.mq_maxmsg * sizeof(struct msg_msg) + - min_t(unsigned int, info->attr.mq_maxmsg, MQ_PRIO_MAX) * - sizeof(struct posix_msg_tree_node); - - mq_bytes = mq_treesize + (info->attr.mq_maxmsg * - info->attr.mq_msgsize); - user = info->user; if (user) { + unsigned long mq_bytes, mq_treesize; + + /* Total amount of bytes accounted for the mqueue */ + mq_treesize = info->attr.mq_maxmsg * sizeof(struct msg_msg) + + min_t(unsigned int, info->attr.mq_maxmsg, MQ_PRIO_MAX) * + sizeof(struct posix_msg_tree_node); + + mq_bytes = mq_treesize + (info->attr.mq_maxmsg * + info->attr.mq_msgsize); + spin_lock(&mq_lock); user->mq_bytes -= mq_bytes; /* -- 2.20.1