All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Daniel Borkmann" <daniel@iogearbox.net>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 1/7] bpf: Reject exclusive maps as inner maps in map-in-map
Date: Mon, 01 Jun 2026 15:18:09 +0000	[thread overview]
Message-ID: <20260601151810.68BCF1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260601150248.394863-2-daniel@iogearbox.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] BPF iterators bypass map exclusivity (`excl_prog_sha`) and map freezing (`map->frozen`) protections, allowing arbitrary modification of secure maps.
--

commit 94f0db1114c682145008741a58e7ea931a088e25
Author: Daniel Borkmann <daniel@iogearbox.net>

bpf: Reject exclusive maps as inner maps in map-in-map

This commit prevents an exclusive map from being inserted into a
map-of-maps. This addresses an issue where unrelated programs could
bypass exclusivity guarantees by accessing the map at runtime.

> diff --git a/kernel/bpf/map_in_map.c b/kernel/bpf/map_in_map.c
> index 645bd30bc9a9d..d2cbab4bdf644 100644
> --- a/kernel/bpf/map_in_map.c
> +++ b/kernel/bpf/map_in_map.c
> @@ -20,7 +20,8 @@ struct bpf_map *bpf_map_meta_alloc(int inner_map_ufd)
>  	/* Does not support >1 level map-in-map */
>  	if (inner_map->inner_map_meta)
>  		return ERR_PTR(-EINVAL);
> -
> +	if (inner_map->excl_prog_sha)
> +		return ERR_PTR(-ENOTSUPP);

[Severity: Critical]
This is a pre-existing issue, but while this patch closes the map-in-map
bypass for exclusive maps, does a similar bypass still exist through BPF
iterators?

Looking at bpf_iter_attach_map() in kernel/bpf/map_iter.c, when a BPF map
iterator is attached via BPF_LINK_CREATE:

	map = bpf_map_get_with_uref(linfo->map.map_fd);
	if (IS_ERR(map))
		return PTR_ERR(map);

// [...]

	if (key_acc_size > key_size || value_acc_size > value_size) {
		err = -EACCES;
		goto put_map;
	}

This function retrieves the target map but appears to lack checks against
map->excl_prog_sha, map->frozen, and BPF_F_RDONLY_PROG.

Furthermore, the iterator context defined in bpf_map_elem_reg_info() sets
up the value argument without the MEM_RDONLY flag:

		{ offsetof(struct bpf_iter__bpf_map_elem, value),
		  PTR_TO_BUF | PTR_MAYBE_NULL },

Because MEM_RDONLY is omitted, the verifier permits BPF programs to perform
direct memory writes to ctx->value.

Could this allow a program to locate the FD of an exclusive, frozen map via
its ID, attach a custom BPF map iterator, and arbitrarily overwrite the
contents of the protected map?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601150248.394863-1-daniel@iogearbox.net?part=1

  reply	other threads:[~2026-06-01 15:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 15:02 [PATCH bpf-next v2 0/7] More gen_loader fixes Daniel Borkmann
2026-06-01 15:02 ` [PATCH bpf-next v2 1/7] bpf: Reject exclusive maps as inner maps in map-in-map Daniel Borkmann
2026-06-01 15:18   ` sashiko-bot [this message]
2026-06-01 15:40     ` Daniel Borkmann
2026-06-01 15:02 ` [PATCH bpf-next v2 2/7] bpf: Drop redundant hash_buf from map_get_hash operation Daniel Borkmann
2026-06-01 15:29   ` sashiko-bot
2026-06-01 15:02 ` [PATCH bpf-next v2 3/7] libbpf: Reject non-exclusive metadata maps in the signed loader Daniel Borkmann
2026-06-01 16:03   ` bot+bpf-ci
2026-06-01 15:02 ` [PATCH bpf-next v2 4/7] libbpf: Skip initial_value override on signed loaders Daniel Borkmann
2026-06-01 15:48   ` bot+bpf-ci
2026-06-01 15:58   ` sashiko-bot
2026-06-01 15:02 ` [PATCH bpf-next v2 5/7] libbpf: Skip max_entries " Daniel Borkmann
2026-06-01 15:02 ` [PATCH bpf-next v2 6/7] selftests/bpf: Adjust verifier_map_ptr for the map's excl field Daniel Borkmann
2026-06-01 16:20   ` sashiko-bot
2026-06-01 15:02 ` [PATCH bpf-next v2 7/7] selftests/bpf: Test that exclusive maps are rejected in map-in-map Daniel Borkmann
2026-06-02  1:40 ` [PATCH bpf-next v2 0/7] More gen_loader fixes patchwork-bot+netdevbpf

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=20260601151810.68BCF1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=sashiko-reviews@lists.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.