From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F36D1C26 for ; Wed, 23 Nov 2022 09:03:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF478C433C1; Wed, 23 Nov 2022 09:03:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1669194184; bh=qN2kHtrKdNxXqy5f+2fE+D32x9gwI09D/dhNa7yXKrE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fD0he6/2KjFmaMwH1plD9A4xk/es4vBDGgdzzzKew8iMB2v2pEzOlclfLEqXgqEA5 qmrpEqdrj0kINp/CtLI03EZGqXHheNgrXm0cR3c6PDo7dpjqh4Nawsc6uJka7qw+Mw GPo9hEffJ3yQCsCgRzdFYbP3U0rJjHJqMujiRgdQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Hawkins Jiawei , Dan Carpenter , Anton Altaparmakov , "chenxiaosong (A)" , syzkaller-bugs , Andrew Morton Subject: [PATCH 4.14 88/88] ntfs: check overflow when iterating ATTR_RECORDs Date: Wed, 23 Nov 2022 09:51:25 +0100 Message-Id: <20221123084551.744086524@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221123084548.535439312@linuxfoundation.org> References: <20221123084548.535439312@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Hawkins Jiawei commit 63095f4f3af59322bea984a6ae44337439348fe0 upstream. Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). Because the ATTR_RECORDs are next to each other, kernel can get the next ATTR_RECORD from end address of current ATTR_RECORD, through current ATTR_RECORD length field. The problem is that during iteration, when kernel calculates the end address of current ATTR_RECORD, kernel may trigger an integer overflow bug in executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. This may wrap, leading to a forever iteration on 32bit systems. This patch solves it by adding some checks on calculating end address of current ATTR_RECORD during iteration. Link: https://lkml.kernel.org/r/20220831160935.3409-4-yin31149@gmail.com Link: https://lore.kernel.org/all/20220827105842.GM2030@kadam/ Signed-off-by: Hawkins Jiawei Suggested-by: Dan Carpenter Cc: Anton Altaparmakov Cc: chenxiaosong (A) Cc: syzkaller-bugs Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- fs/ntfs/attrib.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/fs/ntfs/attrib.c +++ b/fs/ntfs/attrib.c @@ -631,6 +631,14 @@ static int ntfs_attr_find(const ATTR_TYP return -ENOENT; if (unlikely(!a->length)) break; + + /* check whether ATTR_RECORD's length wrap */ + if ((u8 *)a + le32_to_cpu(a->length) < (u8 *)a) + break; + /* check whether ATTR_RECORD's length is within bounds */ + if ((u8 *)a + le32_to_cpu(a->length) > mrec_end) + break; + if (a->type != type) continue; /*