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 7C1F73DC857 for ; Tue, 18 Aug 2026 06:05:23 +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=1787033127; cv=none; b=L12mHDHa6C9YEN4viar1it8fRXL5jiNtgIY3+V4FbH6VnzvOWf9ss0jqykh0cy4z/taPcNRmP6T2RuzHzW2JOLU4jbvpY3oac4J4jKFWCIe9I7Lx8Ox7I8tMnL2Q3+hj7uEm+5AX1/T0FBjOBdxgQHzVlgIhHxMvBxa004ti+kw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787033127; c=relaxed/simple; bh=1LkS/G+9OsupplZ6mJRtjAL7b6Sueeo59VtGh/jXl9s=; h=Message-ID:Date:MIME-Version:To:Cc:From:Subject:Content-Type; b=N6NaUWidy+5OOnLdBF5cPxGJmRTPxvQ1Uyf9TxLeQWMEdfWqtk3TM2HKnpexJ7N4NfcM7F4L8sB2rgi3h56YtvxauNTADyicwdNTNxNGpymaScAr54dfeqs30TgOvg14ZGEDyumv/Mok+bGbtE1eaoVz3SzTMppw0COpvgD5GXc= 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=gwdvM61p; 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="gwdvM61p" Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-384930ca5e2so4761520a91.3 for ; Mon, 17 Aug 2026 23:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787033123; x=1787637923; darn=vger.kernel.org; h=content-transfer-encoding:content-type:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=CSwCC+5VmVEXhaHZ31J0gWRAZYtpFlE4rqplAmPxIF4=; b=gwdvM61p/07oTaUN/IFcQaiAMY2g4ewjIhhWfSaCV0fHHTDW7mSKIPFCcNrhZI2RFd K6tbdDeon1PVu2uBgMEXm8TyGnNrU0A+J2WOyficLj7HXGgJcbTwMlps5fnOglSddQ2L FIdSnMd1LgXi4Whpe8pI7dKzIzTkVkieZvgWibAEKyze4V3eAz79LfDBc3QVaG0M1JJF eu/yj1dIsBEyCE/OsMterm7q37m7QygJtCioGlx1xsPRdEgAuOB6GuUXfrP+ZE6AihEb 1ZixJFPAuGBJs4k3f9sbOKCHW8PR0IdT2YVRFZiothr0jNcGE6jB4WtLhaYsb9PKZuLm p8Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787033123; x=1787637923; h=content-transfer-encoding:content-type:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=CSwCC+5VmVEXhaHZ31J0gWRAZYtpFlE4rqplAmPxIF4=; b=TXc8zn0vizPTYRl4fvE5tWRfgNuVU6MYcKyEGC9LY865ZJ18kqWmwpcoE0M7W3mPEi up1GEPaaNVWxpQxj196t8Hio0mj7CMeLcOIBB2CIgJIU0t6KBm0ZP1yvsVEVYbT+pGvw TLnUOqVDRZ7Ra1oxFPgHtIOaRXBeTFBthe2fHhQXOl8+S1BtT9L+SAmbFNdcBKNh3MF4 WTryUzu+C8ZYr1wv6f9YClseye9G2EQ774IbaxHvMVzNuuuPuy3owT2OORev7mDoX23n Cbp5zkgVjLEhtxxKxg8n0WmoVuBKWgLMh3SDyhfY2XkK1ExBgivKVAYtusEV2/ed9oFP MoCA== X-Forwarded-Encrypted: i=1; AHgh+RpE/8lzozrbRrAtc7JtgQoY+3vA2kN2OZ65YIxwLtp0V98cnrIkCi5ERg5aUfmhlNdgKayqh8s5lLY5Dzc=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+8iAa9MzGsFblYVK8nksPu37gZcJLwvF1QbKdquH2KebDHtGD mSxR2TBeNLXinry9HiGnoUHeN3kAqX+sDMXzWmmRXyB1OOKkMyJCkG54 X-Gm-Gg: AR+sD10AG3Ad3NkLPFFfoxLPEuUkUgsPCup2oyNDA1tkrT0bviLKdwwIRBubEAvHdGG sMRPn5UswyAZy6NQGYW0fVpeeyKxeC0cyFlakZsxy44GrEvkOn6QUjx1fSNC58EqP/+LZgq1RoI 0WWPXzP67/MCiYRqdXU74lBuiZniv+heTMcu+bdQ+FynmXTMADn5J5qrm2bVbxwSW6Ng1MVZOby Fqd5FkEl74qs/c2wZWQQDuNPQlN9iWft5oYSTtC96g4tmah/IQ7jzxDQTuT+kod2nj3UG8GrO6Y Y0EfdwwkotMd9E6jzVKSadDAJL3Z/rLlBY3/36swGIGozd1NFJK5i/XhHr3O14fe2YsqZTwBnCx GGMZqtj01NLO0+Du88MNDNztGNmhXqsJkvq4GyFhe7nK6fXAai/JQDp+IqwQe/JQnPsIhuJO3kc lVUQlrs5TzVcVhDkgS6MCHwLAaxVcA09yk8+ZdtobjJRcCYcPZ3J5he7DOlU+/kqj2rbzOXUc2s 4BiYf6E6WfjZnvmGtFwF+WYAMm5to1hpsr65rfnMzA7R2AZZCaiY5wFNnCXbeb8P9Ys4B8uVbw= X-Received: by 2002:a17:90b:3bce:b0:393:288:29e3 with SMTP id 98e67ed59e1d1-3933e5c8586mr32530273a91.10.1787033122544; Mon, 17 Aug 2026 23:05:22 -0700 (PDT) Received: from [10.0.1.166] (75-172-9-230.tukw.qwest.net. [75.172.9.230]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39531fbb3c5sm7406599a91.9.2026.08.17.23.05.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Aug 2026 23:05:21 -0700 (PDT) Message-ID: <49b4a00a-351b-4eae-8466-feadb1851156@gmail.com> Date: Mon, 17 Aug 2026 23:05:17 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Namjae Jeon , Hyunchul Lee Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org From: Dennis Tighe Subject: [PATCH] ntfs: validate usa_ofs before preserving the update sequence number Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --- Reached by creating a file on a mounted image whose $MFT holds a corrupted free record.  This seems like a fairly low-impact one, but given that it fires KASAN, it felt worth submitting a patch for. The KASAN error that I received on 7.1.7 is listed above. On a RW mount this is a one-shot per image and only trips KASAN when the next page happens to be poisoned. A reproducer is available if you'd like (just reach out privately). Found and fixed with AI assistance.  fs/ntfs/mft.c | 12 +++++++++++-  1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/fs/ntfs/mft.c b/fs/ntfs/mft.c index fd20d7a..271a265 100644 --- a/fs/ntfs/mft.c +++ b/fs/ntfs/mft.c @@ -2333,7 +2333,17 @@ 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)); +        /* +         * The mft record still holds unvalidated, MST-protected on-disk +         * bytes, so m->usa_ofs is untrusted here.  Only preserve the old +         * update sequence number if that offset is in bounds; otherwise +         * leave usn zero so it is not restored below. +         */ +        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