All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "AdetsGithub" <adethyasrinivasan@outlook.com>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: <bpf@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf] bpf: Reject writable map iterators on read-only and frozen maps
Date: Sat, 07 Nov 2026 19:53:40 +0000	[thread overview]
Message-ID: <DMP8PQQ4S8F9.15Q6N6B56KY39@gmail.com> (raw)
In-Reply-To: <LO2P302MB0197FAF0305A94F7575CA700BC752@LO2P302MB0197.GBRP302.PROD.OUTLOOK.COM>

On Sat, Nov 07, 2026 at 06:14 AM AdetsGithub <adethyasrinivasan@outlook.com> wrote:
> The bpf_map_elem and bpf_sk_storage_map iterators pass the live element
> value (ctx->value) to the iterator program as a writable buffer
> (PTR_TO_BUF | PTR_MAYBE_NULL) for all non-percpu map types. Since

Way too long.
With CAP_BPF and CAP_PERFMON an iterator prog writes into a frozen
BPF_F_RDONLY_PROG array.
The verifier treats the content of such array as constants.
That's all that needs to be said.

check_map_load() doesn't exist.
bpftool map dump doesn't use iterators.

> Fixes: 8d0358f6e8b3 ("bpf: Keep iterator programs off special map fields")
> Fixes: d3cc2ab546ad ("bpf: Implement bpf iterator for array maps")
> Fixes: d6c4503cc296 ("bpf: Implement bpf iterator for hash maps")
> Fixes: 5ce6e77c7edf ("bpf: Implement bpf iterator for sock local storage map")

Wrong tags.
8d0358f6e8b3 only added a check.
sk_storage maps cannot have BPF_F_RDONLY_PROG.
Keep d3cc2ab546ad and d6c4503cc296. Drop the other two.
Don't add a5cbe05a6673 that bpf-ci proposed. In that commit
bpf_iter_check_map() returns -EINVAL for every map.


> B) Patched 7.4.0-rc1 -- writable iterator rejected with -EACCES on all phases:
>   ./test_progs -v -t frozen_rdonly_iter_write

Pls add a selftest as patch 2. Not this one. It fails on a fixed kernel.
dump_bpf_array_map() in progs/bpf_iter_bpf_array_map.c writes into
ctx->value. Attach it to an array with BPF_F_RDONLY_PROG, like
"attach_oob_write_iter" in test_bpf_sk_storage_map().
The attach succeeds today. With the fix it returns -EACCES.


> +	if ((map->map_flags & BPF_F_RDONLY_PROG) || READ_ONCE(map->frozen))
> +		return -EACCES;

bpf-ci is right.
BPF_MAP_FREEZE stops the writes from the syscall side only.
Progs can write into a frozen map.
See BPF_MAP_FREEZE in uapi/linux/bpf.h.
bpf_map_is_rdonly() needs BPF_F_RDONLY_PROG, so the flag alone closes
the hole. The flag never changes, so there is no race with map_freeze().
Drop the map->frozen part here and in the comment.

pw-bot: cr

      parent reply	other threads:[~2026-11-07 19:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-07 14:14 [PATCH bpf] bpf: Reject writable map iterators on read-only and frozen maps AdetsGithub
2026-11-07 14:41 ` sashiko-bot
2026-11-07 14:49 ` bot+bpf-ci
2026-11-07 19:53 ` Alexei Starovoitov [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=DMP8PQQ4S8F9.15Q6N6B56KY39@gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=adethyasrinivasan@outlook.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=memxor@gmail.com \
    --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 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.