Re: [PATCH] hugetlb: block hugetlb file creation if hugetlb is not set up

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 28 May 2025 19:51:29 +0200 Jann Horn <jannh@google.com> 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...