All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ziyang Men" <ziyang.meme@gmail.com>
Cc: bpf@vger.kernel.org, tj@kernel.org, sched-ext@lists.linux.dev,
	linux-input@vger.kernel.org, dmitry.torokhov@gmail.com,
	hannes@cmpxchg.org, mkoutny@suse.com
Subject: Re: [PATCH v5 2/4] selftests/cgroup: add memcg_stat_cross_cpu correctness test for flush
Date: Thu, 10 Sep 2026 23:44:30 +0000	[thread overview]
Message-ID: <20260910234430.B37C31F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260910233303.1063501-3-ziyang.meme@gmail.com>

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

Pre-existing issues:
- [High] Kfuncs taking enum parameters lack negative bounds checks, allowing out-of-bounds array accesses.
--

commit ba61caf79f3e8d8099a1b75ad1df31bbdc5f2942
Author: Ziyang Men <ziyang.meme@gmail.com>

selftests/cgroup: add memcg_stat_cross_cpu correctness test for flush
    
Add test_memcg_stat_cross_cpu, which verifies that flushing a memcg
subtree produces the same statistics through the BPF memcg kfuncs and
cgroupfs.

[ ... ]

> diff --git a/tools/testing/selftests/cgroup/memcg_stat_cross_cpu.bpf.c b/tools/testing/selftests/cgroup/memcg_stat_cross_cpu.bpf.c
> new file mode 100644
> index 0000000000000..fff3b9256aa39
> --- /dev/null
> +++ b/tools/testing/selftests/cgroup/memcg_stat_cross_cpu.bpf.c
> @@ -0,0 +1,101 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2026 Meta Platforms, Inc. and affiliates. */
> +#define BPF_NO_KFUNC_PROTOTYPES
> +#include <vmlinux.h>
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_core_read.h>
> +#include "memcg_stat_cross_cpu.h"
> +
> +char _license[] SEC("license") = "GPL";
> +
> +/* Ensure the upper-bound checks also reject negative BPF arguments. */
> +_Static_assert((enum vm_event_item)-1 >= NR_VM_EVENT_ITEMS,
> +	       "negative vm_event_item must fail the bounds check");
> +_Static_assert((enum memcg_memory_event)-1 >= MEMCG_NR_MEMORY_EVENTS,
> +	       "negative memcg_memory_event must fail the bounds check");

[Severity: High]
This is a pre-existing issue, but while these static asserts guarantee the BPF
compiler evaluates the check correctly, does the host kernel kfunc itself
still lack negative bounds checks?

Looking at bpf_mem_cgroup_memory_events() in mm/bpf_memcontrol.c:

	if (unlikely(event >= MEMCG_NR_MEMORY_EVENTS))
		return (unsigned long)-1;

Since the BPF verifier does not validate enum ranges, a BPF program can pass a
negative value as the enum parameter. Because enums can be treated as signed
integers in C, wouldn't a negative value bypass this upper-bound check (e.g.
-1 >= MEMCG_NR_MEMORY_EVENTS evaluates to false), leading to an out-of-bounds
array access?

A similar issue appears to exist in bpf_mem_cgroup_vm_events() which calls
memcg_vm_event_item_valid() in mm/memcontrol.c:

	if (idx >= NR_VM_EVENT_ITEMS)
		return false;

Could this allow an out-of-bounds array read that leaks kernel memory or
causes a panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910233303.1063501-1-ziyang.meme@gmail.com?part=2

  reply	other threads:[~2026-09-10 23:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 23:32 [PATCH v5 0/4] selftests: add shared Makefile for BPF selftests and a new memcg test Ziyang Men
2026-09-10 23:33 ` [PATCH v5 1/4] selftests: add shared lib.bpf.mk to build BPF progs and skeletons Ziyang Men
2026-09-10 23:33 ` [PATCH v5 2/4] selftests/cgroup: add memcg_stat_cross_cpu correctness test for flush Ziyang Men
2026-09-10 23:44   ` sashiko-bot [this message]
2026-09-11  8:03   ` bot+bpf-ci
2026-09-10 23:33 ` [PATCH v5 3/4] selftests/hid: build the BPF program via the shared lib.bpf.mk Ziyang Men
2026-09-11  7:44   ` bot+bpf-ci
2026-09-10 23:33 ` [PATCH v5 4/4] selftests/sched_ext: build BPF schedulers " Ziyang Men
2026-09-11  7:44   ` bot+bpf-ci

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=20260910234430.B37C31F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-input@vger.kernel.org \
    --cc=mkoutny@suse.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sched-ext@lists.linux.dev \
    --cc=tj@kernel.org \
    --cc=ziyang.meme@gmail.com \
    /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.