From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793304995; b=Y22+LUn95KvbomRviYGef/8prN9JUIb4lQQdj+0qy9XQOHTLwnzwIUPhUvdmw+FtsvYU OueApiSWuJ5nbZrVvLqZ/zsfSeXtb493ub/EStrztgZj19ER6wQ6cdoMcEMoSxBp6exCE GkS+HzfDXMqKBFgtvk7TZ89WuazP0RzMZkeaD3fqu3A6SPf69U9og7dbUj8yt7SyvhYBU /siz7F+lV3+fsNpRKVOdVGWLd/Lf85idZXc7ORoZUg3GzFYdjGmYxOVxO7aW2KHWOVck4 e0agiATqgIUlc8LLhGMFHtgQtNEArcN/oxTq10Y1MV+uIDt9CRLIGZx4fbpDEXxxBfg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793304995; h=Received:DKIM-Signature:Message-ID:From:Subject:Reply-To:To:Cc: In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=TJdj+nRxzwmeAlUbfhS7SlRdyBQsSB/cYfiRxhQQbeM=; b=xozTQOcEgte8dYgbr1k4T+9DuHEvehOQ7xz9mnIO3zXWQzqgfxAvqRggB2gibGM9gC3D +foYkqo69TR8Q9aHF14f8K9QdzT9YQ9Rtf/bUdBr9awLkFJzSYCLwjrNE8VhMUFtrfA3F tIlU1fWqb71Zw9ENtHGTadMJ/JzLF4SpuxDqEk30mvmWDgY9cn1xQ3ivNZ9rZwKEdiszh sr8jrQGaytnxr0eV0biPeRxNqm8PqdpKOdFydX0depi7T9ZiitMf2LmV/0mdojs3DqAh3 F8XPCpjgqvuJ4zIdZLy3aZuVrdbhAk73n9GJbtBd/l3dhKTQLVBfE1rZSFyitgLVT7g== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ekfURQHh; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75456606A322 for ; Thu, 29 Oct 2026 20:16:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ekfURQHh Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E7FE1F01816; Thu, 29 Oct 2026 20:16:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793304995; bh=TJdj+nRxzwmeAlUbfhS7SlRdyBQsSB/cYfiRxhQQbeM=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=ekfURQHhnijlxlF7gvSXCpv5eZrLzkWD16UI67gtDggvNCULe+pNqRYtFo/OcoNe5 n3DQColvnI0WFiVzo5TGMyFldBziknPHy2s4kxkPKhlq0786PUKOeEXs+LRnnpXAJf dTQS3V1CHR5bI3GHyPWvRX6eb6rZHdUhtbayYTyEQAGs20A1KK/skqnD8CO676iW3F ifpFWHPNQvtMUOaS5joK/4FOxWe+8VgIjZVLOBQpLI1aCl7r/fPUXpLEKSEWQ7tjH1 SlqeEnny/Yy90g/024Th9vPafB0dlgWaMOuFh2h/GQXYCvYMKYb7clVZrZY/pMxgAL SnYKV4dO4hccw== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH 11/15] hugetlbfs: do not grow a sealed file in mmap() Reply-To: sashiko-reviews@lists.linux.dev To: =?utf-8?b?RGF2aWQgSGlsZGVuYnJhbmQgKEFybSk=?= Cc: linux-s390@vger.kernel.org, "Heiko Carstens" , "Vasily Gorbik" , "Alexander Gordeev" , "Christian Borntraeger" In-Reply-To: <20261028-fixes_hugetlb-v1-11-a0a033db180f@kernel.org> References: <20261028-fixes_hugetlb-v1-0-a0a033db180f@kernel.org> <20261028-fixes_hugetlb-v1-11-a0a033db180f@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2026 20:16:34 +0000 X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list > From: Chris Mason >=20 > hugetlbfs_file_mmap() grows a file when a writable mapping extends beyond > EOF. We are missing seal checks similar to hugetlbfs_setattr() and > hugetlbfs_fallocate(), allowing a user to grow a file that has F_SEAL_GROW > set. >=20 > To fix it, skip the resize when F_SEAL_GROW is set; mmap() still succeeds > without growing the file. >=20 > We currently also allow CoW mappings to grow a file. Disallowing this, > maybe even only for read-only file descriptors, could break existing > userspace, so we have to be more careful. QEMU's file backend is an > example user that might rely on such things, and would suddenly start > getting SIGBUS when faulting in memory outside EOF. >=20 > So be careful and focus on F_SEAL_GROW for now. >=20 > Fix generated by an LLM and sent by Chris Mason in private. >=20 > Fixes: ff62a3421044 ("hugetlb: implement memfd sealing") > Cc: stable@kernel.org > Signed-off-by: Chris Mason > [ david: drop comment; simplify+extend description ] > Signed-off-by: David Hildenbrand (Arm) Sashiko has reviewed this patch and found no issues. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261028-fixes_huge= tlb-v1-0-a0a033db180f@kernel.org?part=3D11