From nobody Mon Apr 6 15:03:05 2026 Received: from mail-oo1-f72.google.com (mail-oo1-f72.google.com [209.85.161.72]) (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 A83D72DCF52 for ; Thu, 19 Mar 2026 05:52:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.72 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773899581; cv=none; b=H98Zb6IQdKsBskTw9c+Wqd0nEPpoeRVpxwTYoKSlPi6NVqaPEyRbf4yUB2ULGPpK8JJlbxCeUcst4LROVfZ8KGcbdUAzayFtTsnxDAfpco+FocCMRPj90rv9uOO0BFp3Md3aPxw9x450+IT6KFt+i2n074/y40Z6Hfx7tDYi/lg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773899581; c=relaxed/simple; bh=UMqMNZfjKeY6nyfwZBWjyItxODK5N8aWpsgzkifL648=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=FkK4kR9A4pm7ktSPUMRwiKxxI9eilPNSJRGSUnFY4qvqCHEsRZVkDkPn5Hk9BThtWRp86L6WXdVzldQBRVDl0M8tkwrcZHruUpKGDkeI2AJrYzwUTQ5Vr2Y2X9HxQB7Zxe0XIsBoukbXHAL5qga0DOVvYudqc0LoNGHRGJEZLKs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.161.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oo1-f72.google.com with SMTP id 006d021491bc7-67c12fc5411so9980742eaf.1 for ; Wed, 18 Mar 2026 22:52:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773899578; x=1774504378; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cxchy99iCLVWDIDcdRNBa/sLESr/a+5y/gakHiygPV0=; b=MFn4LatjzBzhdfIKJ2C1NFwLihRP562nDWPmc60TGcGqozWsPQ4ro3HyFBVbWsNz7I +S+Vg9Xt7Fn4nhXSs/91CewNMSZJ+HYpTlkHR1eeUWAHYBxVNw0MU2mDDfkwDGnn1ihL sh1RnvIJQ8gFGJtOtIveWHSu+IFsmUyepBksU5sBtBKBNxfJgmhaUk6Kw2wS/pZIS66w HwA5rvfKEZ4LobSFuiW/wc6TO/EFYVqab6UgDR+3I4HCifX/wbL2VvWq1RIrAEOq2Qlf NL8KCzbAS7M30ig0IMk8Yf0hcwXYB2b1KR74KKYJA8TRAN6yYbii3oASfGP8w31CI7oH Axdg== X-Gm-Message-State: AOJu0YwqnpFhrrbbtY2FhmRbnbTmsxBPbRp5P96y18QAothJnFS0WVO/ x4IkV4E0NmL2c1sg+tnKMfE03KBScjhzzk/bqloQ+2/8vtWkekQTO3apTHlNWO57KkpjIpLtGfY ceyBBKm1f+7ZAkOSiQiO3KatzpLymnc3MA8E6CdxC/38YMpj4tw86sbP45+w= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:1992:b0:67b:b7ce:12a6 with SMTP id 006d021491bc7-67c181b9b30mr1911289eaf.0.1773899578752; Wed, 18 Mar 2026 22:52:58 -0700 (PDT) Date: Wed, 18 Mar 2026 22:52:58 -0700 In-Reply-To: <699c406b.050a0220.1876f9.0002.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <69bb8f3a.050a0220.227207.001b.GAE@google.com> Subject: Forwarded: [PATCH] fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked() From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] fs/ntfs3: fix missing run load for vcn0 in attr_data_get_b= lock_locked() Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= master When a compressed or sparse attribute has its clusters frame-aligned, vcn is rounded down to the frame start using cmask, which can result in vcn !=3D vcn0. In this case, vcn and vcn0 may reside in different attribute segments. The code already handles the case where vcn is in a different segment by loading its runs before allocation. However, it fails to load runs for vcn0 when vcn0 resides in a different segment than vcn. This causes run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was never loaded into the in-memory run list, triggering the WARN_ON(1). Fix this by adding a missing check for vcn0 after the existing vcn segment check. If vcn0 falls outside the current segment range [svcn, evcn1), find and load the attribute segment containing vcn0 before performing the run lookup. The following scenario triggers the bug: attr_data_get_block_locked() vcn =3D vcn0 & cmask <- vcn !=3D vcn0 after frame alignment load runs for vcn segment <- vcn0 segment not loaded! attr_allocate_clusters() <- allocation succeeds run_lookup_entry(vcn0) <- vcn0 not in run -> SPARSE_LCN WARN_ON(1) <- bug fires here! Reported-by: syzbot+c1e9aedbd913fadad617@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=3Dc1e9aedbd913fadad617 Signed-off-by: Deepanshu Kartikey --- fs/ntfs3/attrib.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c index 6cb9bc5d605c..6ef7db82a35d 100644 --- a/fs/ntfs3/attrib.c +++ b/fs/ntfs3/attrib.c @@ -1152,6 +1152,20 @@ int attr_data_get_block_locked(struct ntfs_inode *ni= , CLST vcn, CLST clen, if (err) goto out; } + + if (vcn0 < svcn || evcn1 <=3D vcn0) { + struct ATTRIB *attr2; + attr2 =3D ni_find_attr(ni, attr_b, &le_b, ATTR_DATA, NULL, + 0, &vcn0, &mi); + if (!attr2) { + err =3D -EINVAL; + goto out; + } + err =3D attr_load_runs(attr2, ni, run, NULL); + if (err) + goto out; + } + da =3D false; /* no delalloc for compressed file. */ } =20 --=20 2.43.0