All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Hwang <leon.hwang@linux.dev>
To: "Ömer Mete Kaya" <omermetekaya0@gmail.com>,
	ast@kernel.org, daniel@iogearbox.net
Cc: andrii@kernel.org, eddyz87@gmail.com, memxor@gmail.com,
	martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev,
	jolsa@kernel.org, emil@etsalapatis.com, ihor.solodrai@linux.dev,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf] bpf: Zero-fill non-target CPU slots on BPF_F_CPU insert of new per-CPU element
Date: Tue, 29 Sep 2026 13:04:39 +0800	[thread overview]
Message-ID: <8fce9ea9-1947-4ec4-9154-cb71fbd75671@linux.dev> (raw)
In-Reply-To: <20260928214932.544124-1-omermetekaya0@gmail.com>

On 29/9/26 05:47, Ömer Mete Kaya wrote:
> pcpu_copy_value() with BPF_F_CPU copies the value only to the target
> CPU's slot and returns immediately, leaving all other CPUs untouched.
> When inserting a *new* element, the backing per-CPU area may be reused
> from bpf_mem_cache or a prealloc freelist without being zero-initialized,
> so non-target CPUs retain stale contents of a previously-deleted
> element in the same map — a same-map information disclosure.
> 
> pcpu_init_value() is used to initialize newly allocated elements, while
> updates to existing elements call pcpu_copy_value() directly; non-target
> CPU slots intentionally retain their previous values there.
> 
> The onallcpus=false path in pcpu_init_value() already handles new
> element initialization correctly by explicitly zeroing non-current CPUs:
> 
>   if (cpu == current_cpu)
>       copy_map_value(..., value);
>   else
>       zero_map_value(...);
> 
> Fix by adding a zero-fill pass in pcpu_init_value() after
> pcpu_copy_value() returns, covering only the BPF_F_CPU new-element
> path: iterate all CPUs and zero-fill every slot except the target.
> This leaves pcpu_copy_value() unchanged so the update-existing-element
> semantics are not affected.
> 
> Fixes: c6936161fd55 ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_hash and lru_percpu_hash maps")
> Signed-off-by: Ömer Mete Kaya <omermetekaya0@gmail.com>
> ---
> Tested with a reproducer:
> - Before the fix: CPU 1 retained 0xDEADBEEFCAFEBABE from the deleted
>   element.
> - After the fix: the non-target CPU read back zero.

Could you add a selftest to prove the issue?

You said a reproducer. But, I don't know what it looks like.

> 
>  kernel/bpf/hashtab.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 8cc07e54daaa..dff4321f2828 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -1099,6 +1099,16 @@ static void pcpu_init_value(struct bpf_htab *htab, void __percpu *pptr,
>  		}
>  	} else {
>  		pcpu_copy_value(htab, pptr, value, onallcpus, map_flags);
> +		if (map_flags & BPF_F_CPU) {
> +			int target = map_flags >> 32;
> +			int cpu;
> +
> +			for_each_possible_cpu(cpu) {

But wait, the 'map_flags & BPF_F_CPU' has been check in the first 'if
()' condition in pcpu_init_value(). See the previous fix:
https://lore.kernel.org/bpf/20260924102321.2120434-1-donggeunyoo.kernel@gmail.com/

Thanks,
Leon

> +				if (cpu != target)
> +					zero_map_value(&htab->map,
> +						       per_cpu_ptr(pptr, cpu));
> +			}
> +		}
>  	}
>  }
> 
> --
> 2.55.0


  parent reply	other threads:[~2026-09-29  5:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 21:47 [PATCH bpf] bpf: Zero-fill non-target CPU slots on BPF_F_CPU insert of new per-CPU element Ömer Mete Kaya
2026-09-28 22:03 ` sashiko-bot
2026-09-29  5:04 ` Leon Hwang [this message]
2026-09-29  7:58   ` Ömer Mete Kaya

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=8fce9ea9-1947-4ec4-9154-cb71fbd75671@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=omermetekaya0@gmail.com \
    --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 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.