Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3760916pxk; Tue, 29 Sep 2020 05:45:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0ujv301wiephUM2ic1LV8/APMvPEGnZnbCIWYhwOkzc7tOkX4tEGXfINaBpceLUy3+u3+ X-Received: by 2002:a17:906:e88:: with SMTP id p8mr3909750ejf.134.1601383506211; Tue, 29 Sep 2020 05:45:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601383506; cv=none; d=google.com; s=arc-20160816; b=yGgu6XOMCaB0W8yAfPiv+u5MPOLx/A8gId8JiUUUZn6LLNPsNBSmMtywwanXAM0f75 pWPN5LP+Naz6VaVofrVVoMvl3fo9nhJDk6FLEVJP3WyTjidsAG79mbYelTnJbHP6ut69 mMUxAGKiKCwBEy62AAltmtju4Angxg228GHZ7vVsupC2x6q9ybbQq/i7ONu2r5PbVsph q4OOjPNbjd1j4sHcsf/PwpLRuDVaeFR+4Sje3kiBe/VK9R6mgqnIw0k7dpWX+edhySbu qWXb7xou70UC6cnb8jIvgPelH1xqgzgWSujretj4af/huCyJsu64uhzfT7l6V/mDqrtP HCuQ== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=RQ3unxmw1OO9sukHaa/Tt8jOneReIc1QsZNffnAjvic=; b=TCJXkKkdA66DaF8QbsKShbQGr4eaOyfoFmXLj5yIr6Tc5eCFNatAA2v1089bxfaJ57 2ReFUYNPcjVk4L7lKJ1VZLF4qboCUV3CI22vOp8wDCrNcFZhtKBGoqnfGhGscrlf7fbW Zvpq+P6eOEz55D2X2bnABWDZD/GL6QJEXhT3WjgtrRyi003/aDfictgOm4deocDJtgz+ X/cBPr0tbab7EJqhozyDpK9B5W3pAEPMv9IvpOg5N62LgM2UsV5XYt9neziQKcONHQzd 51NNvz3SjGLd6nrSkKev/Og1QGZ4+BJpGBrglTiRh9NaJoAgGSN/I66/MNudPrpeRFXU B3Nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DEQi5tvw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a12si2647542edt.557.2020.09.29.05.44.43; Tue, 29 Sep 2020 05:45:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DEQi5tvw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732932AbgI2Mnr (ORCPT + 99 others); Tue, 29 Sep 2020 08:43:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:50316 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729091AbgI2LJs (ORCPT ); Tue, 29 Sep 2020 07:09:48 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (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 71605221EF; Tue, 29 Sep 2020 11:09:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601377786; bh=nV2hnbKtkB2BlDOC4qeSSeGMkvJWmVGMRnEvR21pAkU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DEQi5tvwkE0zJMiVhHqSqx9+ONE8qiEv6ppi01S6N29xA4vy/8UYmiACXBPHw3VpD kuh0tqTpsX819O/EySuf7TpA7Lk7qYqJ8xbw+4R4XuprPJgJq8KjMZ6N5KTY7SIX88 MMNy4lRW0V0PCekp818kTeO4cmGxSXhey770slRI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Liu Song , Richard Weinberger , Sasha Levin Subject: [PATCH 4.9 071/121] ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len Date: Tue, 29 Sep 2020 13:00:15 +0200 Message-Id: <20200929105933.693135346@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200929105930.172747117@linuxfoundation.org> References: <20200929105930.172747117@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Liu Song [ Upstream commit acc5af3efa303d5f36cc8c0f61716161f6ca1384 ] In “ubifs_check_node”, when the value of "node_len" is abnormal, the code will goto label of "out_len" for execution. Then, in the following "ubifs_dump_node", if inode type is "UBIFS_DATA_NODE", in "print_hex_dump", an out-of-bounds access may occur due to the wrong "ch->len". Therefore, when the value of "node_len" is abnormal, data length should to be adjusted to a reasonable safe range. At this time, structured data is not credible, so dump the corrupted data directly for analysis. Signed-off-by: Liu Song Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin --- fs/ubifs/io.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c index 97be412153328..9213a9e046ae0 100644 --- a/fs/ubifs/io.c +++ b/fs/ubifs/io.c @@ -237,7 +237,7 @@ int ubifs_is_mapped(const struct ubifs_info *c, int lnum) int ubifs_check_node(const struct ubifs_info *c, const void *buf, int lnum, int offs, int quiet, int must_chk_crc) { - int err = -EINVAL, type, node_len; + int err = -EINVAL, type, node_len, dump_node = 1; uint32_t crc, node_crc, magic; const struct ubifs_ch *ch = buf; @@ -290,10 +290,22 @@ int ubifs_check_node(const struct ubifs_info *c, const void *buf, int lnum, out_len: if (!quiet) ubifs_err(c, "bad node length %d", node_len); + if (type == UBIFS_DATA_NODE && node_len > UBIFS_DATA_NODE_SZ) + dump_node = 0; out: if (!quiet) { ubifs_err(c, "bad node at LEB %d:%d", lnum, offs); - ubifs_dump_node(c, buf); + if (dump_node) { + ubifs_dump_node(c, buf); + } else { + int safe_len = min3(node_len, c->leb_size - offs, + (int)UBIFS_MAX_DATA_NODE_SZ); + pr_err("\tprevent out-of-bounds memory access\n"); + pr_err("\ttruncated data node length %d\n", safe_len); + pr_err("\tcorrupted data node:\n"); + print_hex_dump(KERN_ERR, "\t", DUMP_PREFIX_OFFSET, 32, 1, + buf, safe_len, 0); + } dump_stack(); } return err; -- 2.25.1