From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A429D23EA83 for ; Thu, 20 Aug 2026 06:42:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787208163; cv=none; b=HrGHarHNL77DuVsHr/bDftzEH3s7S80TmX1Uuounl3LVTe340hIQ0tVB+MM+j6VlC/ZRqso5yepqw87j1e4sdrFBnJ+QNYY7vy2jEiQMcDk3EfKsCyPiy8iESWewTwSc/Nmr67+LkPX7lbnbT6SzEHCCsDPRDob679OKNtHTPQ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787208163; c=relaxed/simple; bh=lJm4ebvKVaxifpJh49jYAtxE3Jr658vnjf+dd9yZuEc=; h=Message-ID:Date:From:To:Cc:Subject:MIME-Version:Content-Type: Content-Disposition; b=LDQdx5uAW3s2DZriqGYY2LIFUoJlBTM2YteOoEBcSJuWVemaqPpesENYaDyH3kLJyGSOIVDratO1Myx4yphVU9Mo6noOa60HFfl97NJCd82+u7UTeEGLHK5tfaEaDSGNyeV8paKOoy0JEZ8GGbMuR4x6NhDXkzluVUveZPda5zY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NlhKzxCJ; arc=none smtp.client-ip=209.85.216.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NlhKzxCJ" Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-38deea72eebso1946080a91.1 for ; Wed, 19 Aug 2026 23:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787208162; x=1787812962; darn=vger.kernel.org; h=content-disposition:content-type:mime-version:subject:cc:to:from :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ySKcbNvx111V9QjBY3CXX8m1j0vcfzMaXNZH3TRNdiE=; b=NlhKzxCJj2EMfmLTY2MGG9DOgtW3QM5zwSTRYDFvC2PuI8U0fFzXoesqEhZ9Mlc1QR Jrxzs/BEOyY3nVw+YOcnEwdFuRcLeUAtHxFrFg0VdowIY0VjrmFYaC+ziqRFQ1JqfDRn VnUImNH1AQ0yI3EHmf7FUD96ZlFdov+7vewjIw+2Cgw3D4SNpo4Vs3oKS24TKPvm98kO ZlQkYNT0iMAdbvzsBA0Z7pnqy9o+ms6bqZBRJG6uhSnQDJGI2n38CSiwIhyAyElG45Z2 N6LI5gojqYKWnHBgghwci+UrPxG7QEmDTFckeXKiY01LlQ/ze24PPFC6BhZZaBjDq1Xz gplg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787208162; x=1787812962; h=content-disposition:content-type:mime-version:subject:cc:to:from :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ySKcbNvx111V9QjBY3CXX8m1j0vcfzMaXNZH3TRNdiE=; b=QvXR2a22JuD4qf0TDoH7mkJ8ObUUGAbhiZxhD57z4fFWOrRcvn4DYxJ8bYBp6Trqja ZBuSBRdIc05AhbvcMoAT3VKWlh9q59e0Ts4pwOdUsR5NZ+q4mgNBg95UjVDVu4uo11T1 r9b6Zu5LCbFfnMnOf9hN8HD8mFfRPhfJ3dY1dXeeyHYmawfylCYrGByOTHYCC2Dwv8aH KpSWI28Bajz3UOtuRktUbGnONZJUvSJY2DlP5tRn9Hu6VQQZgo1RTmSiW8xRzBL3ziSq h8vhYVAx3MmZv5cllV1Q/W2V8jft1O4lLIcYnKukFiRbt6O5QSNDUXj/4zuqmwHUhhF2 nN0A== X-Forwarded-Encrypted: i=1; AHgh+RoMFEb3eUebVzbcAbcI0Vuinhyf30EVZhk48gnz0mnsxAb/hrLQxzrgcrWuqCPpJJkT7S8AWpjSyGVrVzw=@vger.kernel.org X-Gm-Message-State: AFuF++no7peBeZLw6IiGAn38UlJN02g6tP17G5Ski929R7rw9/mFNQeT st34Xz0Lpox1/gnst6JAlPtvMlWQcgNEydRdxg+cYmq4RP9ATc/JT07O X-Gm-Gg: AR+sD116kvWmOprZO+0wBHjEh+w5Y37OV5ZxyZrA0S4IClvaeGDZNhQY68w7L7vtBGs y3TnRVifUvRIV9lz2usLWp4P8JE0NHA72D8Ms+rVnOYPVHdQUJGlfdC/L4qw9pg9iLCbwUy/hur GfO232BSmF6wa5ktCm2ltmcSYGufcWwSytDl9dcRpw+G2sWPj7/wzDK7ZNC2KgIpPgqbuSxb1TP W3sKGrD0pi4mhyarknwHy6ady3nuSqDfJrad3iB9fkCdpELtRut8/QP5sh3r5aKqCl713IBqItu 8w5DLRnxuWS6sz+Ox7zFDDBZRjW2mJgKvQnGwDzqiDUstjN4IGWc+n0Nl0MLGRD4Fq744JmUFI1 QPy49ZVyUTY5azzGAWGodcOWH+42s8bSFsJQgyZ6lGD1QwXp0rHrfdHxLD3+kyyI19TfBOHpcVJ 4JfbIG8qH3feTwHnTzx7+9krMImcn+7wqf/LAnvt1PECXL4Vr8LFK5rL4iuLKPrk+9Pt3W2nFZ2 2AkaBbMq0FFCp67jcFukSfoslt/kbh21D4JRNPoT9QHiA== X-Received: by 2002:a17:90b:5250:b0:38d:b36e:9813 with SMTP id 98e67ed59e1d1-395810b57d1mr19603977a91.11.1787208161795; Wed, 19 Aug 2026 23:42:41 -0700 (PDT) Received: from localhost (75-172-9-230.tukw.qwest.net. [75.172.9.230]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1416ad69638sm12205170c88.7.2026.08.19.23.42.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2026 23:42:41 -0700 (PDT) Message-ID: <6a86a1e1.ee10049a.267d65.9802@mx.google.com> X-Google-Original-Message-ID: Date: Wed, 19 Aug 2026 23:42:36 -0700 From: Dennis Tighe To: Namjae Jeon , Hyunchul Lee Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] ntfs: validate usa_ofs before preserving the update sequence number Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline When ntfs_mft_record_alloc() reuses a free mft record it reads the old update sequence number straight from the on-disk record: usn = *(__le16 *)((u8 *)m + le16_to_cpu(m->usa_ofs)); Here m points into the raw $MFT page-cache folio, which still holds unvalidated, MST-protected bytes: the folio is read by a plain iomap_read_folio() and neither post_read_mst_fixup() nor ntfs_mft_record_check() has run on it (both work on private copies). m->usa_ofs is therefore an untrusted u16, and a corrupted record can put it past the end of the record so the two-byte read lands outside the folio. Reading such a record while creating a file gives, under KASAN: BUG: KASAN: use-after-free in ntfs_mft_record_alloc+... Read of size 2 at addr ... ntfs_mft_record_alloc -> __ntfs_create -> ntfs_create -> path_openat Only preserve the old update sequence number when usa_ofs is even and in range, mirroring the check ntfs_mft_record_check() already applies; otherwise leave usn zero, which the existing restore below skips. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe --- For v2: - drop the explanatory comment above the check (per review). - fix blankspace issues fs/ntfs/mft.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/ntfs/mft.c b/fs/ntfs/mft.c index fd20d7a..82d2190 100644 --- a/fs/ntfs/mft.c +++ b/fs/ntfs/mft.c @@ -2333,7 +2333,11 @@ int ntfs_mft_record_alloc(struct ntfs_volume *vol, const int mode, * wrong with the previous mft record. */ seq_no = m->sequence_number; - usn = *(__le16 *)((u8 *)m + le16_to_cpu(m->usa_ofs)); + if (!(le16_to_cpu(m->usa_ofs) & 1) && + le16_to_cpu(m->usa_ofs) + sizeof(usn) <= vol->mft_record_size) + usn = *(__le16 *)((u8 *)m + le16_to_cpu(m->usa_ofs)); + else + usn = 0; err = ntfs_mft_record_layout(vol, bit, m); if (unlikely(err)) { ntfs_error(vol->sb, "Failed to layout allocated mft record 0x%llx.", -- 2.47.3