From: sashiko-bot@kernel.org
To: "Samiullah Khawaja" <skhawaja@google.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Muchun Song" <muchun.song@linux.dev>,
"Oscar Salvador" <osalvador@suse.de>
Cc: "David Hildenbrand" <david@kernel.org>,
"Jeff Xu" <jeffxu@google.com>,
"Daniel Verkamp" <dverkamp@chromium.org>,
"David Matlack" <dmatlack@google.com>,
"Pasha Tatashin" <tatashin@google.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] hugetlbfs: enforce F_SEAL_EXEC on chmod
Date: Tue, 27 Oct 2026 20:56:09 +0000 [thread overview]
Message-ID: <sashiko-outbox-187105@kernel.org> (raw)
In-Reply-To: <20261026205555.2918396-1-skhawaja@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] hugetlbfs: uninitialized info->seals read in hugetlbfs_setattr() on root dir
--
commit 42d3d553628462e4f19c0be00708f922ba1aa705
Author: Samiullah Khawaja <skhawaja@google.com>
hugetlbfs: enforce F_SEAL_EXEC on chmod
This commit adds a check for F_SEAL_EXEC to hugetlbfs_setattr() so that mode
changes modifying execute bits on sealed hugetlbfs memfds fail with -EPERM.
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 01c4d6f44ebe0..56e0588d295d9 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -842,6 +842,10 @@ static int hugetlbfs_setattr(const struct mnt_idmap *idmap,
>
> trace_hugetlbfs_setattr(inode, dentry, attr);
>
> + if ((info->seals & F_SEAL_EXEC) && (ia_valid & ATTR_MODE) &&
> + ((inode->i_mode ^ attr->ia_mode) & 0111))
> + return -EPERM;
[Severity: High]
Could this read uninitialized memory from info->seals when setattr is called
on a hugetlbfs mount root directory?
hugetlbfs_setattr() is also used as the .setattr callback in
hugetlbfs_dir_inode_operations. While inodes created via
hugetlbfs_get_inode() initialize info->seals to F_SEAL_SEAL, the root
directory inode allocated in hugetlbfs_get_root() does not initialize seals:
fs/hugetlbfs/inode.c:hugetlbfs_get_root() {
inode = new_inode(sb);
if (inode) {
inode->i_ino = get_next_ino();
inode->i_mode = S_IFDIR | ctx->mode;
inode->i_uid = ctx->uid;
inode->i_gid = ctx->gid;
simple_inode_init_ts(inode);
inode->i_op = &hugetlbfs_dir_inode_operations;
inode->i_fop = &simple_dir_operations;
HUGETLBFS_I(inode)->resv_map = NULL;
...
}
Because new_inode() -> hugetlbfs_alloc_inode() allocates from
hugetlbfs_inode_cachep without __GFP_ZERO, and the slab constructor
init_once() only calls inode_init_once(&ei->vfs_inode), HUGETLBFS_I(inode)->seals
is left uninitialized on fresh slab allocations and retains stale values when
a slab object is recycled from a previously closed hugetlbfs memfd.
Previously, hugetlbfs_setattr() only checked info->seals inside the
ATTR_SIZE block, which was unreachable for directories. With this check placed
outside ATTR_SIZE, any chmod, chown, or utimensat on the root directory of a
hugetlbfs mount reads uninitialized or stale info->seals, and chmod changing
any 0111 bit on the root directory can spuriously fail with -EPERM if the
slab object previously belonged to a memfd with F_SEAL_EXEC set.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261026205555.2918396-1-skhawaja@google.com?part=1
prev parent reply other threads:[~2026-10-27 20:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 20:55 [PATCH] hugetlbfs: enforce F_SEAL_EXEC on chmod Samiullah Khawaja
2026-10-26 21:08 ` David Hildenbrand (Arm)
2026-10-27 20:56 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-187105@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=dmatlack@google.com \
--cc=dverkamp@chromium.org \
--cc=jeffxu@google.com \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=sashiko-reviews@lists.linux.dev \
--cc=skhawaja@google.com \
--cc=tatashin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.