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 DB8841C29 for ; Wed, 23 Nov 2022 09:38:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 439C4C433D6; Wed, 23 Nov 2022 09:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1669196325; bh=9+ZLJWZ+edbJ5SV64rjAhzZBWoWw/nYmvN4vTgXSXP4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DGvYo4gS5IcFo3ck2I1/du5IBiIGjzf8hCSkvCssZsaIluqUE5BwkbIwgEGYwsKHs aI87tdw1io6hIKsM2a4NHPyuyKNJfUsDhvVUVVCRRtgkedT8ZOsP4YzDBsnSxmpKHL 9sQi0va2ZpCdj0tlnGm/OSwOC4GK+EAUqvsx/0Rw= 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 5.15 181/181] ntfs: check overflow when iterating ATTR_RECORDs Date: Wed, 23 Nov 2022 09:52:24 +0100 Message-Id: <20221123084610.185707949@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221123084602.707860461@linuxfoundation.org> References: <20221123084602.707860461@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 @@ -617,6 +617,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; /*