Re: [PATCH bpf-next v4 1/8] bpf: Use mapping tree to zap arena VMAs

["Emil Tsalapatis" <emil@etsalapatis.com>]

On Thu Oct 15, 2026 at 12:33 AM UTC, bot+bpf-ci wrote:
>> bpf: Use mapping tree to zap arena VMAs
>
> TL;DR: Per-arena anon inode is no longer S_PRIVATE, so under SELinux arena
> creation, mmap and fd passing may now be denied for existing policies. Was
> this intended? Commit message doesn't mention it.

Yes, it is intended as it is the only way to add anonymous inodes per-arena. We
need those to properly close out in subsequent patches the races already present
in the code. Specifically, it lets us add exclusion between frees and arena VM
faults without introducing a deadlock caused by mmap_lock(). I will mention this
in the description.

We can also make a shared arena anonymous inode at init time and marking it as 
private would avoid introducing additional checks on arena-related calls, at the
cost of traversing all mapped arena VMAs in the system. I don't think that's too
crazy a cost and it would keep existing semantics unchanged.

>
>> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
>> --- a/kernel/bpf/arena.c
>> +++ b/kernel/bpf/arena.c
>
> [ ... ]
>
>> @@ -326,12 +330,18 @@ static struct bpf_map *arena_map_alloc(union bpf_attr *attr)
>>  	if (err)
>>  		goto err_free_scratch;
>>  	mutex_init(&arena->lock);
>> -	mutex_init(&arena->zap_mutex);
>>  	raw_res_spin_lock_init(&arena->spinlock);
>>  	err = populate_pgtable_except_pte(arena);
>>  	if (err)
>>  		goto err_destroy_rt;
>>
>> +	arena->file = anon_inode_create_getfile("bpf-map", &arena_backing_fops,
>> +						NULL, O_RDWR, NULL);
>> +	if (IS_ERR(arena->file)) {
>> +		err = PTR_ERR(arena->file);
>> +		goto err_destroy_rt;
>> +	}
>> +
>>  	return &arena->map;
>
> Does switching arena fds from the shared S_PRIVATE anon inode to a
> per-arena inode from anon_inode_create_getfile() change LSM behavior in a way
> the commit message doesn't mention?
>
> anon_inode_create_getfile() creates a !S_PRIVATE inode and calls the
> inode_init_security_anon() hook:
>
>     inode = alloc_anon_inode(sb);
>     inode->i_flags &= ~S_PRIVATE;
>     ...
>     error = security_inode_init_security_anon(inode, &QSTR(name), context_inode);
>
> Under SELinux this looks like it has two new effects for
> BPF_MAP_TYPE_ARENA.
>
> First, map creation now runs the anon inode create check:
>
>     map_create() -> map_create_alloc() -> arena_map_alloc()
>       -> anon_inode_create_getfile()
>         -> selinux_inode_init_security_anon()
>
>     return avc_has_perm(sid, isec->sid, isec->sclass, FILE__CREATE, &ad);
>
> A policy that doesn't grant the caller's domain anon_inode { create } on the
> transitioned "bpf-map" type would now fail arena creation with -EACCES,
> which the PTR_ERR() above returns to userspace.
>
> Second, every arena fd built by arena_map_get_file() via alloc_file_clone()
> of arena->file has an inode without S_PRIVATE.  Previously
> inode_sid_has_perm() returned early for the shared anon inode:
>
>     if (unlikely(IS_PRIVATE(inode)))
>         return 0;
>
> That early return no longer applies.  mmap() of the arena
> (selinux_mmap_file() -> file_map_prot_check() -> __file_has_perm() ->
> inode_has_perm()) and passing the fd over SCM_RIGHTS or binder
> (selinux_file_receive() -> file_has_perm()) would now need anon_inode
> { read write map } permission on that label, including in the receiving
> domain.
>
> Other map types keep the old unlabeled behavior because they still use
> anon_inode_getfd(), so only arena fds get these checks.  Existing
> SELinux-enforcing setups whose policy was written for the old behavior, such
> as a loader daemon that creates maps and hands the fds to confined
> applications, could start seeing denials on arena creation or mmap.  The
> later patches in this series still call anon_inode_create_getfile(), so this
> isn't changed there.
>
> Was the new LSM labeling intended?  If the goal is only a unique inode and
> mapping, could the old S_PRIVATE, unlabeled semantics be kept instead, or
> could the commit message at least document the new policy requirements?
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/38657686181