From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54B88C5AE59 for ; Tue, 3 Jun 2025 03:41:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA0EB6B039B; Mon, 2 Jun 2025 23:41:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B51BB6B039C; Mon, 2 Jun 2025 23:41:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A677A6B039D; Mon, 2 Jun 2025 23:41:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 883946B039B for ; Mon, 2 Jun 2025 23:41:12 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EA682121DDF for ; Tue, 3 Jun 2025 03:41:11 +0000 (UTC) X-FDA: 83512688742.03.BBB364B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 34F6A120004 for ; Tue, 3 Jun 2025 03:41:10 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="piEY/2iy"; dmarc=none; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748922070; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9ZmHIqeruRUkGLg9NZ1rETrIeadNTtaAZChsoA9AdFI=; b=vwDw0FTW+v0pSAwO5scq4+tpkYo1haKuZLBN8zTgSum3umrVaLkxERjMF4qeiIEnjHFGEH cLLTRFQg6D5sVpfcK7yq9Nw9Fhei0Px3bnxaxOiDPZl14Ep4FPj8wwoipBLBLJkY3v2gUw KTxPM5YXD5ABo17zRfVJfyTbq/Y+Wqk= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="piEY/2iy"; dmarc=none; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748922070; a=rsa-sha256; cv=none; b=f6Oj70OldiBw/qa2DOS7vPIGgHXjCwPFZv2ocMbNVRQWT3ALJrj8kyAXMugyn7YHtLTSSZ f7zip2Ysgos32kXtC6q/r9dDQyNCmukJdZCjygg4cgpohxxzaPSWzdfxIJ26NHlm87y1QD eUSgzf1UApkY/2KN1qTunw5kKIpGmKo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3D73F5C56AC; Tue, 3 Jun 2025 03:38:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DBDAC4CEEB; Tue, 3 Jun 2025 03:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1748922068; bh=lgRpuGhoSUGV+k6ftFRoAV3iGG0zJg4dFM0bFon82nY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=piEY/2iyefskzQcSK6FzDeuECnB/o1T6nW3d8nv89rEtPy0pC+l6mNssRZadgObcx zp0gd/sDCHwcr0p+EKlJznyKhtnOWTONR+LcmcqWBQ225QMIsQakDYaz30184/dg3A bNZg48Fc7xPdBNcwJZDmHtlKStQBbp62szLDOKNY= Date: Mon, 2 Jun 2025 20:41:07 -0700 From: Andrew Morton To: Jann Horn Cc: Muchun Song , Oscar Salvador , linux-mm@kvack.org, Lorenzo Stoakes Subject: Re: [PATCH] hugetlb: block hugetlb file creation if hugetlb is not set up Message-Id: <20250602204107.177e2fdf2209b0926b5ce28e@linux-foundation.org> In-Reply-To: <20250528-hugetlb-nerf-v1-1-a404ca33e819@google.com> References: <20250528-hugetlb-nerf-v1-1-a404ca33e819@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 34F6A120004 X-Stat-Signature: yzi4pnoyatqd5pq6uf8it7yg73948d4g X-Rspam-User: X-HE-Tag: 1748922070-106977 X-HE-Meta: U2FsdGVkX19r0NqrO35AIGvmBY4LtDjG1GwjsiqjLkXm67BzCsqbRt49WpHybug8pxj1SUbiBYWczm+NqE0eYwXbtwks7+K5IgmNzX1mf8Ve6QKXvG+09L5EGGtUx3wRq/uxhVFuTLVFgvOy0yH2PJnl5XmoT1l/RYC2aF+6KnIst3b63mhr70R07mr520Q9EqabGMVqiWwTaEFEL/zeBE6aGRjMPwXhPUn+cPJnxi09fLIJd22To6uOjOSAqyDWAMeuGv+NfHJHxqlfGSWrxL8EVMZzsXIYGhvJQpMYV1gBOra0+DzKttwyZwKxrvSVmZDkrQqbcchFFxSxCg79R11JLs+84WD32GOMo0s4JjBBFhsStAl0UtIeasVlioVN3rxVa+Z5J2Em7kZvzyyzZApm+d3XUHQ0RHSwSagUdi1A6zKzK06xaVHv08j9xlInhhn4hgxBGGscaKGg5GBRY22L8i6GL/OItOMwxopM3mMD/OfHr3MM0KPNxmTF9NW32LdYr3zEKGQ/XsfqMa3vtpRcdJDxvJxM0nEDJFjc1S04qenO7Pccs//thRV3Y3Z8ytvVnPLATwZjgpHFcL6bq7XV9eLp38sMA606BBa4xAzQ8K6p3cqjh8lAPkXYJKw4rvZFA7rUm/tz+1zKOVTurNuZFIeY3yWorvPZksrMlBWJklyUTNOxpgSJDhrt8tujyoh9rqyO+a8jKnMIILjTKmY8FCooNnAPZaCKNzOcj/yhdU/2K8TxcYzLz1TKqBQUmUt9V6ydGBOJ/QiHZJUwQwTIMqKnP1EJWxlmLoeZM0cxCw904egCM89DMrnTskq+/4nzp4RJd4cbNAXr9KrGhRa7YCkLc/PMYv1/Pzryfueao2kstWR8qbRNQPKlhXMIk85hKVeOcvFRsB7TA2L3UFhIPJMK2WphqmXmWknyJO1kzSS2wzdPdNUsVrpQvcOG5c0nu81AbCdVPaDcbmR oJN6/xDR 5edhbOCuXDzEhQ1OenopUdAhSl3VNCQAyHvfONHEkFfGJE8EY76TfeF1K87v1MKWneBsUrY6BpVofoHUSILZs3ycbE6tZKyWTp9Qu49cQJXGLKn3MDH1iEULRbiUFdRY07HSKJebiPi8Y1Q1iwhNeQkCMo89pmmWMT7KGGfA2Z0avJRvQJZtdP5GtOZcKk2C3rmvuZLQ1i10mjLl3kLyrHOBxwIf7tOzaiZqKiuCvW1X8El3BmadxVqFutjAMBMh8ENWEKFO6KDbykTI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 28 May 2025 19:51:29 +0200 Jann Horn wrote: > Many distro kernels enable hugetlb support, but most systems running > those kernels never actually allocate hugepages or enable hugetlb > overcommit. > > On such systems, hugetlb is unusable for any legitimate usecase, but it > is still possible to exercise a lot of hugetlb-specific code by creating > MAP_HUGETLB|MAP_NORESERVE VMAs - for example, it is still possible to > create page tables shared across processes. > > This is exposed through the mmap() syscall, with no privileges required, > so from a security perspective, this is interesting attack surface. > > Lock it down by completely denying creation of hugetlb files if no huge > pages for the hstate could be allocated without administratively > changing huge page limits. So this is a non-backward-compatible change? If any userspace is affected it's probably either stupid or evil, but I do wonder if there are legit cases for doing this, such as "I don't know if there are any hugepages configured, but I'll try this anyway and figure out what to do later on". And maybe there are other legit cases! Clearly any such cases will be obscure but please let's consider the worst-case effects upon existing userspace? > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -1517,6 +1517,16 @@ static int get_hstate_idx(int page_size_log) > return hstate_index(h); > } > > +static bool hstate_is_enabled(struct hstate *h) > +{ > + bool is_enabled; > + > + spin_lock_irq(&hugetlb_lock); > + is_enabled = h->nr_overcommit_huge_pages || h->max_huge_pages; > + spin_unlock_irq(&hugetlb_lock); > + return is_enabled; > +} > + > /* > * Note that size should be aligned to proper hugepage size in caller side, > * otherwise hugetlb_reserve_pages reserves one less hugepages than intended. > @@ -1549,6 +1559,15 @@ struct file *hugetlb_file_setup(const char *name, size_t size, > return ERR_PTR(-EPERM); > } > > + /* > + * If no hugetlb pages of this size are supposed to exist, then don't > + * even allow creating a hugetlb file (even if the file has size 0 or > + * userspace requests MAP_NORESERVE). > + * This limits attack surface for systems that don't use hugetlb. > + */ > + if (!hstate_is_enabled(HUGETLBFS_SB(mnt->mnt_sb)->hstate)) > + return ERR_PTR(-ENOMEM); > + > file = ERR_PTR(-ENOSPC); > /* hugetlbfs_vfsmount[] mounts do not use idmapped mounts. */ > inode = hugetlbfs_get_inode(mnt->mnt_sb, &nop_mnt_idmap, NULL, Yes it's hard to imagine that this will cause damage...