mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: bot+bpf-ci@kernel.org
To: leon.hwang@linux.dev,bpf@vger.kernel.org
Cc: ast@kernel.org,daniel@iogearbox.net,john.fastabend@gmail.com,andrii@kernel.org,martin.lau@linux.dev,eddyz87@gmail.com,song@kernel.org,yonghong.song@linux.dev,kpsingh@kernel.org,sdf@fomichev.me,haoluo@google.com,jolsa@kernel.org,shuah@kernel.org,leon.hwang@linux.dev,linux-kernel@vger.kernel.org,linux-kselftest@vger.kernel.org,kernel-patches-bot@fb.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 1/2] bpf: Disallow BPF_F_LOCK with mixed special fields and centralize flag checks
Date: Thu, 22 Jan 2026 16:02:11 +0000 (UTC)	[thread overview]
Message-ID: <df8fb7dc501dd081fcba56b592cba94e5aecd614ea4d3b595155dec551ecbca5@mail.kernel.org> (raw)
In-Reply-To: <20260122153120.69249-2-leon.hwang@linux.dev>

[-- Attachment #1: Type: text/plain, Size: 2925 bytes --]

> 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.

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

  reply	other threads:[~2026-01-22 16:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 15:31 [PATCH bpf-next 0/2] bpf: Disallow BPF_F_LOCK with mixed special fields Leon Hwang
2026-01-22 15:31 ` [PATCH bpf-next 1/2] bpf: Disallow BPF_F_LOCK with mixed special fields and centralize flag checks Leon Hwang
2026-01-22 16:02   ` bot+bpf-ci [this message]
2026-01-22 16:18     ` Leon Hwang
2026-01-22 15:31 ` [PATCH bpf-next 2/2] selftests/bpf: Add tests to verify BPF_F_LOCK restrictions Leon Hwang

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=df8fb7dc501dd081fcba56b592cba94e5aecd614ea4d3b595155dec551ecbca5@mail.kernel.org \
    --to=bot+bpf-ci@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=clm@meta.com \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kernel-patches-bot@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=leon.hwang@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®