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=1794063030; b=iKB5+dDsntjhKif8SelPU51yt4Q5AWvtEcw34TwgDzIN8ncvELDEIuPh5ime+jTImKuT Jw6vFbMSlGQ9WlqFbEA3ihg9GSJwVa2Ng5vTJrGfwAy+bRUXO6FWBqDFwprt6lSRPw3GY i62iMUtf3lh5QDFMfw+fY7IWZfCOgW09rY3EHzFVT+Jh71LvYIvPvwVY17Uk+WgbLt1Qq qc9hgyomW3mlokWGBccXxOUnFqgNgMCg7zviOkKjN8AIqFz48jqg52jX8OzKrokBJLU2i ob9+kR6Up3aAqkb7oq6wJCcDYdC6HVrorQfgNVujXMQ472nI43KxGMSKmMG8XyY5x0A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794063030; 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=t6L4RuMGNbjyl9WlBYBqxw7Cj30C+3b06dy3HEriPhY=; b=xCGk1zaeZAxKJfBm1uLvwkMQfEZd0/lMq23+N7P6rEPGhdncmJZcuRSm9p5g7V88vZnj 1VsJWOU5HmVlG9z21V8SQUaE40mp9TE3cGiN9GsCBd2oDcdo6SwHfrogVgf/TNJNCxYB0 t38OAOsj+bnrJhRRJLMxs8YjQ/LWRa9cQ0aeUfAF5d5O/h17R0sA/21+11hzOA49bP7xe KjU6YP/or24VRKlt8uDsLZBRfWqOqSvoS6QOLbr0dWo0mjks8MNFq7VPd62s/9xBCc9RJ WIF/rTD1c2anBrb57LLXB4pbz2pIDY4BIJkTV4AiCkeeMrSu3vm3ZCwq8BHC2gZBTIA== 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=E8FegisK; 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 733F4606D80F; Sat, 7 Nov 2026 14:50:30 +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=E8FegisK Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20B7D1F0089F; Sat, 7 Nov 2026 14:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794063030; bh=t6L4RuMGNbjyl9WlBYBqxw7Cj30C+3b06dy3HEriPhY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=E8FegisKejJnTLHbJbdr+7EuRhnny0dZbin279U+8g/CNyh79A0g1m4B6PhhZWIWB BpF9BIJJToXIJoIjmu15O/LGLn2Sx4HwwvpXem/2mdxPztSMLzbU0nInPVjpdh8XpO i/NeJd8olD7grKoJm6V4g+COuxrBDlCApLsZZS/s= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Ibrahim Hashimov , Konstantin Komarov , Sasha Levin Subject: [PATCH 6.18 280/869] fs/ntfs3: fix integer overflow in find_log_rec() causing OOB read Date: Sat, 7 Nov 2026 08:49:22 -0500 Message-ID: <20261107134901.202482147@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261107134852.069646174@linuxfoundation.org> References: <20261107134852.069646174@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 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ibrahim Hashimov [ Upstream commit e2fcb0040b0b4097b2e97f3fbe77d3b66df9e816 ] find_log_rec() validates the on-disk LFS_RECORD_HDR.client_data_len field (`len`, a raw u32 read straight from a mounted $LogFile page) against the log's total available space: len = le32_to_cpu(rh->client_data_len); rec_len = len + log->record_header_len; if (rec_len >= log->total_avail) return -EINVAL; The addition is unchecked. For len in [0xffffffd0, 0xffffffff] (i.e. log->record_header_len away from UINT_MAX), `rec_len` wraps to a small u32 value that trivially clears the `rec_len >= log->total_avail` guard, so a record whose declared length is actually ~4 GiB is reported as valid and in-page. Because find_log_rec() wrongly accepts the record, its caller read_log_rec_lcb() hands it back to log_replay() as good. On the transaction-table replay leg, log_replay() re-derives the record length directly from the same raw, still-unclamped client_data_len field and uses it to size the restart-table blob: rec_len = le32_to_cpu(frh->client_data_len); /* ~0xffffffff */ ... t16 = le16_to_cpu(lrh->redo_off); rt = Add2Ptr(lrh, t16); t32 = rec_len - t16; /* still ~4 GiB */ if (!check_rstbl(rt, t32)) return -EINVAL; check_rstbl()'s own `bytes < ts` bounds guard is defeated because the caller-supplied `bytes` (t32) is itself the poisoned ~4 GiB value, so the guard can never trigger. The subsequent entry-validation loop then walks `rt->used` (also attacker-controlled) entries of sizeof(struct RESTART_TABLE) == 0x18 bytes each straight past the end of the kmalloc(log->page_size) log-page buffer allocated in read_log_page(), producing an out-of-bounds read that is reachable simply by mounting a crafted $LogFile (no genuine dirty-page / crash-recovery state is required). Confirmed via KASAN as a slab-out-of-bounds read in check_rstbl(), called from log_replay() -> ntfs_loadlog_and_replay() -> ntfs_fill_super() -> mount(2). Fix the root cause instead of hardening every downstream consumer of the poisoned length: make the addition in find_log_rec() overflow-safe with check_add_overflow(), mirroring the pattern fs/ntfs3/run.c already uses to validate other attacker-controlled on-disk length/offset arithmetic decoded from MAPPING_PAIRS runs, e.g.: if (check_add_overflow(vcn64, len, &next_vcn)) return -EINVAL; ... if (check_add_overflow(lcn, len, &lcn_end)) return -EINVAL; (fs/ntfs3/run.c, run_unpack()). With the overflow rejected instead of silently wrapped, `rec_len` is only ever a true, non-wrapped sum, so the existing `rec_len >= log->total_avail` check now correctly rejects any oversized record up front. log_replay()'s transaction-table leg then never gets a chance to re-read the poisoned client_data_len, and check_rstbl() is never invoked with an attacker-inflated `bytes` for this path. Verified on a v6.19 KASAN build: mounting a crafted $LogFile whose client_data_len overflows trips a KASAN slab-out-of-bounds-read report in check_rstbl() before this fix; with check_add_overflow() applied, the same image is cleanly rejected during log replay and no KASAN report fires. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin --- fs/ntfs3/fslog.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/ntfs3/fslog.c b/fs/ntfs3/fslog.c index ae15c2fc48646..ca3533a10d064 100644 --- a/fs/ntfs3/fslog.c +++ b/fs/ntfs3/fslog.c @@ -7,6 +7,7 @@ #include #include +#include #include #include @@ -2455,7 +2456,8 @@ static int find_log_rec(struct ntfs_log *log, u64 lsn, struct lcb *lcb) * Check that the length field isn't greater than the total * available space the log file. */ - rec_len = len + log->record_header_len; + if (check_add_overflow(len, log->record_header_len, &rec_len)) + return -EINVAL; if (rec_len >= log->total_avail) return -EINVAL; -- 2.53.0