From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794065099; b=oeY9kOFCimXCQE8nY3WTSYac5a3eD7ZzkYCFw37L9pIOdmwGW64AzBjIui4dkKysfuP8 9D8HLllcNEiqE4cbHQcXGESA172aZQlUrfPJHqE4nzxERSqvE1R4pz7DAUbv2gE+OteNP KcQvW/jelJaizhyZzGr28wpfUdLyDs3xP6sqXeAFCTEEZKSKhhi9diP+MRXFimohMxPt/ dR4hD7nzYNC7nyLXXWH1h5z6s9xAaEw3ZP9qLayUj7HtJMb6iJLT3ISe5a5nroQfqzfEA zsliIPE9UVotPFt799Cq+H0VDrEWzNS7gJTd7YqtZZgTJnHYOwexoiboEsYYLl7ZkBw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794065099; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=EOEYUeg+wakqaELsGCz1NM7PSM1X6jmi0pesx1z2y18=; b=D04tgxWzxLydtYy3fwE+cZmEnp44zWGrWkFc9Y5ApwNEn+2gsMlYZsSR4TkyrvBlrXrl 4e/dFC8l9li2rinEnSOiYvECW8fpwTheXmTRafwZKkxXeeOSRzySBKwTC0RLGENU++Rzi 9IDLbT8q0m+CM9V5WonnYITz7dcwWYP2t2rLO9lDj5jggZT3ISb6xf3Pb9FxJfWqjeOY/ OjMVIGYpWU6d8oCEKhIW9ZaqH5svohHPDARhGiFm9KCTThaERVvscLZtEEdWHG+ZoY/+n VEQbiER0gNb+6FRC+NQ0vSM4ekfWx3LBsyNGaSxImfDKZWTT53cJyDae9d+o3DtsiRw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=XDJC4INa; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 59537606A32C; Sat, 7 Nov 2026 15:24:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=XDJC4INa Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0483F1F0089F; Sat, 7 Nov 2026 15:24:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794065099; bh=EOEYUeg+wakqaELsGCz1NM7PSM1X6jmi0pesx1z2y18=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XDJC4INaEKH1xIJWDXKe7pJHIPXUl7n23xSDMiwAQgLFGyg3d2lS2Ts1vkoerIUe4 QOtyYWtNVBWELpTePznn+GE3MofOBYi/Yng2AZYc65BIYb9IJsECkmqTySGblsn7OK +RRScSEPftRfHIajz3euF3x9XB9EaWZnQL3L3TxM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Matthias Goergens , Hyunchul Lee , Namjae Jeon , Sasha Levin Subject: [PATCH 7.3 0932/1257] ntfs: fail the mount when $MFTs data size exceeds its allocation Date: Sat, 7 Nov 2026 08:53:48 -0500 Message-ID: <20261107135005.097301862@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261107134939.434104957@linuxfoundation.org> References: <20261107134939.434104957@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Matthias Goergens [ Upstream commit 82a5e003ef09113c10b791d687297ef455bb1552 ] ntfs_read_inode_mount() takes $MFT's i_size from data_size without checking it against allocated_size, unlike the resident case in ntfs_read_locked_inode(). mft records between the two are not on disk. On a crafted volume with 512-byte clusters whose $MFT is cut to 4 clusters while data_size still says 27 records, reading the folio holding records 0-3 finds the end of the runlist at vcn 4. An unpatched kernel hangs there on the folio lock, as in "ntfs: fail the mount when $MFT needs its own extent records". With the previous patch vcn 4-7 are past the allocation and so read as a hole: records 2 and 3 come back as zeros and the mount carries on until check_mft_mirror() finds the zeroed record 2. Refuse such a $MFT before anything is read through it. The mount now fails with: ntfs: (device vda): ntfs_read_inode_mount(): $MFT data size 27648 exceeds its allocated size 2048. $MFT is corrupt. Run chkdsk. fs/ntfs3 rejects any non-resident attribute whose data_size exceeds its allocated size. This patch checks only $MFT; the next one covers the other non-resident attributes. Fixes: b041ca562526 ("ntfs: update iomap and address space operations") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin --- fs/ntfs/inode.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c index ca7e2299a8a48..213c4a12b33aa 100644 --- a/fs/ntfs/inode.c +++ b/fs/ntfs/inode.c @@ -2136,6 +2136,16 @@ int ntfs_read_inode_mount(struct inode *vi) vi->i_size = le64_to_cpu(a->data.non_resident.data_size); ni->initialized_size = le64_to_cpu(a->data.non_resident.initialized_size); ni->allocated_size = le64_to_cpu(a->data.non_resident.allocated_size); + /* + * Records between allocated_size and data_size are not + * on disk, and would be read as zeros. + */ + if (vi->i_size > ni->allocated_size) { + ntfs_error(sb, + "$MFT data size %lld exceeds its allocated size %lld. $MFT is corrupt. Run chkdsk.", + vi->i_size, ni->allocated_size); + goto put_err_out; + } /* * Verify the number of mft records does not exceed * 2^32 - 1. -- 2.53.0