linux-kernel - Re: [PATCH bpf-next 1/2] bpf: Disallow BPF_F_LOCK with mixed special fields and centralize flag checks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3fdcdea9-3f09-452e-bd6c-717294f288d6@linux.dev>
Date: Fri, 23 Jan 2026 00:18:28 +0800
From: Leon Hwang <leon.hwang@...ux.dev>
To: bot+bpf-ci@...nel.org, bpf@...r.kernel.org
Cc: ast@...nel.org, daniel@...earbox.net, john.fastabend@...il.com,
 andrii@...nel.org, martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org,
 yonghong.song@...ux.dev, kpsingh@...nel.org, sdf@...ichev.me,
 haoluo@...gle.com, jolsa@...nel.org, shuah@...nel.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
 kernel-patches-bot@...com, martin.lau@...nel.org, clm@...a.com,
 ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next 1/2] bpf: Disallow BPF_F_LOCK with mixed special
 fields and centralize flag checks



On 2026/1/23 00:02, bot+bpf-ci@...nel.org wrote:
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index 5936f8e2996f..c5863487ee73 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -3935,9 +3935,16 @@ static inline int bpf_map_check_op_flags(struct bpf_map *map, u64 flags, u64 all
>>  	if ((u32)flags & ~allowed_flags)
>>  		return -EINVAL;
>>
>> +	/* BPF_NOEXIST and BPF_EXIST are mutually exclusive. */
>> +	if ((flags & (BPF_NOEXIST | BPF_EXIST)) == (BPF_NOEXIST | BPF_EXIST))
>> +		return -EINVAL;
>> +
>>  	if ((flags & BPF_F_LOCK) && !btf_record_has_field(map->record, BPF_SPIN_LOCK))
>>  		return -EINVAL;
>>
>> +	if ((flags & BPF_F_LOCK) && btf_record_has_field(map->record, ~BPF_SPIN_LOCK))
>> +		return -EOPNOTSUPP;
>> +
>>  	if (!(flags & BPF_F_CPU) && flags >> 32)
>>  		return -EINVAL;
> 
> [ ... ]
> 
>> diff --git a/kernel/bpf/bpf_local_storage.c b/kernel/bpf/bpf_local_storage.c
>> index e2fe6c32822b..80b50091cbbf 100644
>> --- a/kernel/bpf/bpf_local_storage.c
>> +++ b/kernel/bpf/bpf_local_storage.c
>> @@ -493,13 +493,6 @@ bpf_local_storage_update(void *owner, struct bpf_local_storage_map *smap,
>>  	unsigned long flags;
>>  	int err;
>>
>> -	/* BPF_EXIST and BPF_NOEXIST cannot be both set */
>> -	if (unlikely((map_flags & ~BPF_F_LOCK) > BPF_EXIST) ||
>> -	    /* BPF_F_LOCK can only be used in a value with spin_lock */
>> -	    unlikely((map_flags & BPF_F_LOCK) &&
>> -		     !btf_record_has_field(smap->map.record, BPF_SPIN_LOCK)))
>> -		return ERR_PTR(-EINVAL);
>                 ^^^^
> 
> This validation was removed from bpf_local_storage_update() but it appears
> that no call to bpf_map_check_op_flags() was added in the local storage map
> update functions. For array and hash maps, calls to bpf_map_check_op_flags()
> were added in array_map_update_elem() and htab_map_update_elem(). However,
> the local storage update functions like bpf_cgrp_storage_update_elem(),
> bpf_fd_inode_storage_update_elem(), and bpf_fd_sk_storage_update_elem() pass
> map_flags directly to bpf_local_storage_update() without calling
> bpf_map_check_op_flags() first.
> 
> The syscall path does call bpf_map_check_op_flags() in map_update_elem() with
> allowed_flags set to ~0, which catches the NOEXIST/EXIST mutual exclusion and
> BPF_F_LOCK validation. But with allowed_flags=~0, the check for unknown flags
> ((u32)flags & ~allowed_flags) always passes zero, meaning unknown flags like
> 8 or 16 would not be rejected.
> 

Correct.

Such flags should indeed be rejected in the local storage update path.

Thanks,
Leon


> The old check (map_flags & ~BPF_F_LOCK) > BPF_EXIST rejected any unknown flag
> bits. Is there a missing call to bpf_map_check_op_flags() in the local storage
> update functions that should specify the allowed flags?
> 
>> -
>>  	if (gfp_flags == GFP_KERNEL && (map_flags & ~BPF_F_LOCK) != BPF_NOEXIST)
>>  		return ERR_PTR(-EINVAL);
> 
> [ ... ]
> 
> 
> ---
> 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/21254704407