Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3758226pxk; Tue, 29 Sep 2020 05:40:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxWV/LH/Q4yYwO2YICity716bK4ipsij/F0J+Icnv1J5aqeIWNB1xZm8owUdmfeRAsz1j7c X-Received: by 2002:a17:906:8399:: with SMTP id p25mr3601651ejx.243.1601383245390; Tue, 29 Sep 2020 05:40:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601383245; cv=none; d=google.com; s=arc-20160816; b=y2bzHtBmdim6zN57axKSFF69jeQCbU+klN27A/bPa5nNQV4BYA+4UvNZeeI9CU8SEK Fj7tzi1yzHRmVSKXMjOHUMblkZVI2FtTUn62FUm4Y9XIflCIXmBPueyveoN4pm0/u2nA Qn6I9iMG9RLNlUpfPRnJf8mTglhNerX9G94tRj6fI8riEwaYy6tDl9jEqZKmAw85W30N Tf7Iny5M+UdxQHSMbcZpKTR8HxiGWPRjo8O/js5jjx0abXoHY746aHg0XgivlVlvpVXd P+bV42NhZ0PYnVFE5a3qY/8ebtKxgoAbrZb4CIqCzOy4e70SatEe7VK5QF0dbFu9WVUs pSDQ== 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=QXoLwscHfET66wpT332FkodDCOZz5LNkHTlM59+nh60=; b=wIvt3aLoiLs2Su/eBSjoVhZs0kHs9h3Z1jCmZIGsJ5YJFmc/AzlMKDjoVAxDUbQmq+ Wc8YEQuu2lX7ky+gfKIGJSjJydAdqxWAyv9/+i7AYZ3r713Wk/OclnA//BjuHBSm5Zgr Rz78K3rn3kDkj0PNstiocUpOBpozF09ER3HnBz4V4R7jAkSOvJE7d2IDzeQVT30uJ4zH ohft5DHssf0JRytXBptDKvrF+OuNpNqMD0gDGzcIFubEvsMlffVEKhPuR0Q4zycomNw1 iPMuN2j/XKS0V7jqrxftAvUTMZk/ZParCGMc/PFfr4d3fPDkQC+HkTGXpfFNGnkeq6uP MKNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=eEeg+3wh; 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 bg3si2683648ejb.616.2020.09.29.05.40.22; Tue, 29 Sep 2020 05:40:45 -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=eEeg+3wh; 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 S1732931AbgI2MjT (ORCPT + 99 others); Tue, 29 Sep 2020 08:39:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:33150 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729215AbgI2LQd (ORCPT ); Tue, 29 Sep 2020 07:16:33 -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 BAB9E206A5; Tue, 29 Sep 2020 11:16:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601378193; bh=AqA6bP1h8ijqZCinl0AVbp3aibhB8ghtiFSesZNMSow=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eEeg+3whZ+zSIYkqXOTrwzOsHo/L97rriDVIVfyyYaKJa2EzxhxWBDbhFq9OW32V4 zlq4livAa2NpzIlasDJurSuP66gvtB8U6N2bMcnaIhsMMewnsZmCa+V9D8nSEXNZdI HPx2Dfrnt/V9F61UEQ/28qJbk2BQwlLKTi1irsNM= 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.14 095/166] ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len Date: Tue, 29 Sep 2020 13:00:07 +0200 Message-Id: <20200929105939.957172399@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200929105935.184737111@linuxfoundation.org> References: <20200929105935.184737111@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 3be28900bf375..135e95950f513 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