Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp3999865pxb; Mon, 27 Sep 2021 07:21:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEYEmChV4GPR11PhifAuLLJ4Z9oQs0faMfAyWleYnH4St5//YVDHvn6giBL0MHfaOtGT/7 X-Received: by 2002:a17:906:308d:: with SMTP id 13mr306456ejv.570.1632752459971; Mon, 27 Sep 2021 07:20:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632752459; cv=none; d=google.com; s=arc-20160816; b=rgiOI54umI4gi8XgqzadGBfujPHoj4ihG//9NwrxSfNJyz3ezxhWMd0k3wNZG295qw ngkghwIhvPQbypls2fXN5S6lDJ32rvC4Vb0sIORDjJh9giKfyF7vHO0rPJY+0DPxmgFl 7/tJPE2OXW1AzXCdhVc65GeRsB+ngt6+f18W0kNDlAPkLZ7yjQ+pyXiWGhD6Q+tzApLO +h81H5X1BJu+8OPASoxE4U8XIBGo4J2+kghKFV0O661DBPmW5luqOVw+ytSP2HiVLIPv 0WOqbx2nJKbIhWhbN2Xdi2xw3JeDb/KdBmgFk5TlggmbSsjDPjCwMy9DN4pBDVOsLkd9 G5/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ADWSPKEy+LIIpoLe1U0zxWcjoXt0BVOeeH5oLm2Cy6E=; b=kYAADhW5JbdSPvH88rrxPN1nTegEnX/uvojO09TDwjwP50JlHmS9d4kxQj6XoqZQrS qCTmNOMclTgJxFzLZnDMMqZlCg6OzaK0NhF2QZBJKFQGwdK+JnDKH0JnVSD/WHMMVbjX OMrntS0nxworFUCbyDQhDnQwm++XLTtWfsa8ZoaX+7rVn8ibmz6WBQzaIGTbFRbpaj07 JUitNjKnjlmk//FrvZLmvQuCTsm3ZzIwZGRtj2ir5UgarS8glS6IiTiKe0MWY6+3fMZG uBYI05zG7J2WaZlMv/s7htMaGEwV4/BPkJfAIwFlVa2KpAmya8Aok/oKS3rAl15Wu1bb IyrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lWN3Hznr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i4si6256207ejo.494.2021.09.27.07.20.34; Mon, 27 Sep 2021 07:20:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lWN3Hznr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234756AbhI0OUB (ORCPT + 99 others); Mon, 27 Sep 2021 10:20:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:60416 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234692AbhI0OT5 (ORCPT ); Mon, 27 Sep 2021 10:19:57 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 606DF60EC0; Mon, 27 Sep 2021 14:18:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632752299; bh=i9UA8nXi2HqSCrUratcAGO/xQHmPOF8KqMc7/yV/Nx8=; h=From:To:Cc:Subject:Date:From; b=lWN3HznredrNPSogAcloFJ7fALhgrsrfvdpwQPrcfjP3LL7HV94IG4hnBe4G5onNY pxef/9s4A0ksQlGrAEZmSYaXktzR3KQVkfNtzotbI/SDVVX1ioTdoWjdtFqRPBicPI 5MsUzK2V6VY5vjHb6BL9Kj+cC7z+fCq9skAYNHHArneYOg2S6+dfmUYvduMdUFVh1y pBGFHaT0HgG6K2REL1tlSz0oWLY4VC4vC9UqlYfz/jQZbb3TV3A0DYWUInFukB79iI 9ShpZmeaCqCMOAJqfUl+Tbw255L+iIeCC932O+ErohqGLFKjIX5YCMyIm8crsC4nWl OY/rqJE9CNBiw== From: Arnd Bergmann To: Anton Altaparmakov , Kees Cook , Andrew Morton Cc: Arnd Bergmann , linux-ntfs-dev@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: [PATCH] [RFC] ntfs: disable for 64KB because of stack overflow risk Date: Mon, 27 Sep 2021 16:18:03 +0200 Message-Id: <20210927141815.1711736-1-arnd@kernel.org> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann On ARM64 randconfig builds, we occasionally get warnings for NTFS: fs/ntfs/aops.c: In function 'ntfs_write_mst_block': fs/ntfs/aops.c:1328:1: error: the frame size of 2224 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] The problem here is that with 64KB pages, we get two arrays on the stack that each have 128 pointers, for a total of 2KB. Before the VLA change, this could already happen with 512-byte blocks, however in practice NTFS should usually have 4KB blocks and not be affected by this (see link). Now the stack usage is always > 2KB on any architecture with 64KB pages. Since both NTFS and 64KB page support are fairly rare, we may get away with just marking the combination as disallowed in Kconfig and see if anyone complains before we find a different way to address it. Fixes: ac4ecf968acb ("ntfs: aops: remove VLA usage") Link: https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs-fat-and-exfat Signed-off-by: Arnd Bergmann --- fs/ntfs/Kconfig | 1 + fs/ntfs/aops.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig index 1667a7e590d8..b770f0209b9c 100644 --- a/fs/ntfs/Kconfig +++ b/fs/ntfs/Kconfig @@ -2,6 +2,7 @@ config NTFS_FS tristate "NTFS file system support" select NLS + depends on !PAGE_SIZE_64KB && !ARM64_64K_PAGES help NTFS is the file system of Microsoft Windows NT, 2000, XP and 2003. diff --git a/fs/ntfs/aops.c b/fs/ntfs/aops.c index bb0a43860ad2..76d59bd4c1eb 100644 --- a/fs/ntfs/aops.c +++ b/fs/ntfs/aops.c @@ -914,6 +914,9 @@ static int ntfs_write_mst_block(struct page *page, bool sync, is_mft, page_is_dirty, rec_is_dirty; unsigned char bh_size_bits; + /* Two arrays of MAX_BUF_PER_PAGE on the stack risks an overrun with 64K pages */ + BUILD_BUG_ON(PAGE_SIZE >= 65536); + if (WARN_ON(rec_size < NTFS_BLOCK_SIZE)) return -EINVAL; -- 2.29.2