From nobody Fri Apr 3 11:12:47 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57016218EB1; Thu, 5 Mar 2026 02:14:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772676886; cv=none; b=R289jYQuLdpY3MUpRZpd+VevMVDQKT94b3/GCbuZ5d0j2cnU3JkI7h8zsV861uXdIIwN+mLZ0bxEj3jW1JoADwoHNuM6lsVTmRhhmH6FuikXFa/5zJxq50DRrs0nbvgh0nendzm2Y1v19/2GcMgaqYn7H3wPtrOqAFr1HCe9QIA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772676886; c=relaxed/simple; bh=s1ocLErcAjuwF4nelrw6ep/ytdRjDP+3h0fLK/z0sK4=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=csBDpnnCWSBJNppAHGoCsEDR6vW6Siux8gpvmh/26FNkuhB/Ra7C678KTNNJ/+cSxzoKeXU6v9vnm8tnJ3UAH6qYys+E6IBK4Wt5G+XRGc9iyNojirP5lLM/NZ8XQ+f5tOlvP4J5GWdyyHtWHZ6zOyQeOk/D7yXuR29ybiZvdi8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=b+N4O5jQ; arc=none smtp.client-ip=117.135.210.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="b+N4O5jQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=bv FMvfmFv/PpBCw8PUJrWR0vV7noWZJWs5tu0GeSyo4=; b=b+N4O5jQpww41uCtpZ LvZ1hvffy9PXFzt5SU7qsAY7ndxmnf9Ovelep/izpOUIA2KilhlRmtqAicTyK6KM l3fha32Wf84YAdOfKUgfz2YFyPOVPlN3Dj8YzoM2k8vCogNxZ8nMVZ1hpXDizeuz Kx28VGtohcSu7QE5TVmpduzhw= Received: from pek-lpg-core6.wrs.com (unknown []) by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id _____wD3d6X65qhpi1O9QQ--.39033S2; Thu, 05 Mar 2026 10:14:19 +0800 (CST) From: Rahul Sharma To: gregkh@linuxfoundation.org, stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Pedro Demarchi Gomes , syzbot+f4f84b57a01d6b8364ad@syzkaller.appspotmail.com, Konstantin Komarov , Rahul Sharma Subject: [PATCH 6.1.y] ntfs: set dummy blocksize to read boot_block when mounting Date: Thu, 5 Mar 2026 10:14:17 +0800 Message-Id: <20260305021417.3956903-1-black.hawk@163.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wD3d6X65qhpi1O9QQ--.39033S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxJF1UKr1UAr18tw1UtFyUGFg_yoW8Kr4Upa 4rAF1fCrWvgryUZasFgrWrXwn5W3yvka4DtrW7Xr17ZryxK3WftFn7tryfXrWqvrW3XrZa qFn8ZFWxtryUuaUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zuXdYAUUUUU= X-CM-SenderInfo: 5eoduy4okd4yi6rwjhhfrp/xtbC3Rt8Fmmo5vt+YwAA3t Content-Type: text/plain; charset="utf-8" From: Pedro Demarchi Gomes [ Upstream commit d1693a7d5a38acf6424235a6070bcf5b186a360d ] When mounting, sb->s_blocksize is used to read the boot_block without being defined or validated. Set a dummy blocksize before attempting to read the boot_block. The issue can be triggered with the following syz reproducer: mkdirat(0xffffffffffffff9c, &(0x7f0000000080)=3D'./file1\x00', 0x0) r4 =3D openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=3D0x4000) mount(&(0x7f0000000140)=3D@nullb, &(0x7f0000000040)=3D'./cgroup\x00', &(0x7f0000000000)=3D'ntfs3\x00', 0x2208004, 0x0) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0) Here, the ioctl sets the bdev block size to 16384. During mount, get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)), but since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leaves sb->s_blocksize at zero. Later, ntfs_init_from_boot() attempts to read the boot_block while sb->s_blocksize is still zero, which triggers the bug. Reported-by: syzbot+f4f84b57a01d6b8364ad@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Df4f84b57a01d6b8364ad Signed-off-by: Pedro Demarchi Gomes [almaz.alexandrovich@paragon-software.com: changed comment style, added return value handling] Signed-off-by: Konstantin Komarov [ The context change is due to the commit c39de951282d ("fs/ntfs3: Improve alternative boot processing") in v6.8 which is irrelevant to the logic of this patch. ] Signed-off-by: Rahul Sharma --- fs/ntfs3/super.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c index 674a16c0c66b..7cf52b70987b 100644 --- a/fs/ntfs3/super.c +++ b/fs/ntfs3/super.c @@ -693,6 +693,11 @@ static int ntfs_init_from_boot(struct super_block *sb,= u32 sector_size, =20 sbi->volume.blocks =3D dev_size >> PAGE_SHIFT; =20 + /* Set dummy blocksize to read boot_block. */ + if (!sb_min_blocksize(sb, PAGE_SIZE)) { + return -EINVAL; + } + bh =3D ntfs_bread(sb, 0); if (!bh) return -EIO; --=20 2.34.1