All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zhiling Zou" <zhilinz@nebusec.ai>, bpf@vger.kernel.org
Subject: Re: [PATCH net 1/1] bpf: reject raw iteration over managed sk_storage values
Date: Thu, 15 Oct 2026 12:24:38 +0000	[thread overview]
Message-ID: <sashiko-outbox-172791@kernel.org> (raw)
In-Reply-To: <1fa798d444efac579e91ee0716e228902a8f9afe.1791980149.git.zhilinz@nebusec.ai>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: bpf_link_update bypasses iterator map->record safety check
--

commit 756d826567f6b13fb5453e6e861ce172e85fb4c1
Author: Zhiling Zou <zhilinz@nebusec.ai>

bpf: reject raw iteration over managed sk_storage values

The sk_storage iterator exposes values as raw memory. This commit attaches
validation checks against value_size to prevent BPF programs from modifying
BTF-managed fields like kptrs.

> diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
> index 1d295a8769fad..b54fd90d4bde9 100644
> --- a/net/core/bpf_sk_storage.c
> +++ b/net/core/bpf_sk_storage.c
> @@ -863,6 +863,12 @@ static int bpf_iter_attach_map(struct bpf_prog *prog,
>  	if (map->map_type != BPF_MAP_TYPE_SK_STORAGE)
>  		goto put_map;
>  
> +	/* The iterator exposes values as raw buffers, bypassing field checks. */
> +	if (map->record && prog->aux->max_rdwr_access) {
> +		err = -EACCES;
> +		goto put_map;
> +	}

[Severity: High]
This security check is only performed during initial attachment. Can this be
bypassed using link replacement?

If an initial BPF iterator program is loaded with max_rdwr_access == 0,
attached to an sk_storage map containing managed fields, and then replaced via
bpf_link_update with a program where max_rdwr_access > 0, won't it bypass
this check?

Looking at bpf_iter_link_replace() in kernel/bpf/bpf_iter.c:

static int bpf_iter_link_replace(struct bpf_link *link,
				 struct bpf_prog *new_prog,
				 struct bpf_prog *old_prog)
{
	...
	if (link->prog->type != new_prog->type ||
	    link->prog->expected_attach_type != new_prog->expected_attach_type ||
	    link->prog->aux->attach_btf_id != new_prog->aux->attach_btf_id) {
		ret = -EINVAL;
		goto out_unlock;
	}

	old_prog = xchg(&link->prog, new_prog);
	...
}

It swaps the program without checking the new program's max_rdwr_access
against the attached map's BTF record.

> +
>  	if (prog->aux->max_rdwr_access > map->value_size) {
>  		err = -EACCES;
>  		goto put_map;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1791980149.git.zhilinz@nebusec.ai?part=1

  reply	other threads:[~2026-10-15 12:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 12:24 [PATCH net 0/1] bpf: reject raw iteration over managed sk_storage values Zhiling Zou
2026-10-14 12:24 ` [PATCH net 1/1] " Zhiling Zou
2026-10-15 12:24   ` sashiko-bot [this message]
2026-10-15 17:01   ` Amery Hung

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=sashiko-outbox-172791@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=zhilinz@nebusec.ai \
    /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.