BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yun Lu" <luyun_611@163.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 5/6] bpf: Check async callback value membership in the setter
Date: Wed, 11 Nov 2026 04:43:36 +0000	[thread overview]
Message-ID: <sashiko-outbox-208308@kernel.org> (raw)
In-Reply-To: <20261111024333.228633-6-luyun_611@163.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] bpf: missing map usercnt check in __bpf_async_set_callback()
--

commit a30152ffd79aa0871058c367266aaec41f12d33b
Author: Yun Lu <luyun@kylinos.cn>

bpf: Check async callback value membership in the setter

This commit checks map element membership in __bpf_async_set_callback() so
that timers and workqueues initialized on deleted map elements cannot have a
callback installed and started.

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index 716be7a852b58..9fa75bcd5e77f 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -1552,11 +1552,25 @@ static int __bpf_async_set_callback(struct bpf_async_kern *async, void *callback
>  				    struct bpf_prog *prog)
>  {
>  	struct bpf_async_cb *cb;
> +	struct bpf_map *map;
>  
>  	cb = READ_ONCE(async->cb);
>  	if (!cb)
>  		return -EINVAL;
>  
> +	/*
> +	 * The prog can still hold a value of an element that was deleted from the map.
> +	 * bpf_async_cancel_and_free() is done with it and nothing stops a new callback
> +	 * when the element is freed. cb is published at this point: either the lookup
> +	 * doesn't find the element or bpf_async_cancel_and_free() finds cb.
> +	 * Nothing runs without callback_fn. An idle cb stays in the element until the
> +	 * element is reused or freed.
> +	 */
> +	smp_mb();
> +	map = READ_ONCE(cb->map);
> +	if (!map || !bpf_map_value_is_linked(map, cb->value))
> +		return -ENOENT;
> +
>  	return bpf_async_update_prog_callback(cb, prog, callback_fn);
>  }

[Severity: High]
Does __bpf_async_set_callback() also need to check atomic64_read(&map->usercnt)
and return -EPERM when it is zero?

Because __bpf_async_init() leaves an idle cb attached to an unlinked element
in a non-preallocated hash or rhash map's bpf_mem_alloc cache while
map->usercnt > 0, a subsequent bpf_map_put_uref() only walks linked elements
in htab_free_malloced_internal_structs() / rhtab_map_free_internal_structs()
and never clears that unlinked element's cb.

If a loaded BPF program then recycles that element back into the map via
bpf_map_update_elem() after map->usercnt has reached 0, copy_map_value()
preserves the timer/wq field and bpf_map_value_is_linked() succeeds here.
Installing cb->prog after map_release_uref() has already run pins the BPF
program and map in a permanent reference cycle, or allows a callback on an
inner map to race with non-synchronous cancellation in htab_map_free() /
rhtab_map_free() and use the freed map and element after they are kfreed.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111024333.228633-1-luyun_611@163.com?part=5

  reply	other threads:[~2026-11-11  4:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11  2:43 [PATCH bpf-next v3 0/6] bpf: Fix async callback use-after-free on map deletion Yun Lu
2026-11-11  2:43 ` [PATCH bpf-next v3 1/6] bpf: Mark task work FREED before detaching it Yun Lu
2026-11-11  3:26   ` sashiko-bot
2026-11-11  2:43 ` [PATCH bpf-next v3 2/6] bpf: Check task work value membership before scheduling Yun Lu
2026-11-11  8:19   ` bot+bpf-ci
2026-11-11  2:43 ` [PATCH bpf-next v3 3/6] selftests/bpf: Test task work scheduling on a deleted value Yun Lu
2026-11-11  2:43 ` [PATCH bpf-next v3 4/6] bpf: Invalidate async callbacks before detaching them Yun Lu
2026-11-11  4:22   ` sashiko-bot
2026-11-11  2:43 ` [PATCH bpf-next v3 5/6] bpf: Check async callback value membership in the setter Yun Lu
2026-11-11  4:43   ` sashiko-bot [this message]
2026-11-11  2:43 ` [PATCH bpf-next v3 6/6] selftests/bpf: Test wq set_callback on a deleted value Yun Lu

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-208308@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=luyun_611@163.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox