[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <873455n4vo.fsf@linux.dev>
Date: Fri, 19 Dec 2025 20:39:39 -0800
From: Roman Gushchin <roman.gushchin@...ux.dev>
To: bot+bpf-ci@...nel.org
Cc: bpf@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
inwardvessel@...il.com, ast@...nel.org, daniel@...earbox.net,
shakeel.butt@...ux.dev, mhocko@...nel.org, hannes@...xchg.org,
mhocko@...e.com, andrii@...nel.org, martin.lau@...nel.org,
eddyz87@...il.com, yonghong.song@...ux.dev, clm@...a.com,
ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next v2 4/7] mm: introduce BPF kfuncs to access
memcg statistics and events
bot+bpf-ci@...nel.org writes:
>> diff --git a/mm/bpf_memcontrol.c b/mm/bpf_memcontrol.c
>> index 2d518ad2ad3f..d84fe6f3ed43 100644
>> --- a/mm/bpf_memcontrol.c
>> +++ b/mm/bpf_memcontrol.c
>> @@ -78,6 +78,57 @@ __bpf_kfunc void bpf_put_mem_cgroup(struct mem_cgroup *memcg)
>> css_put(&memcg->css);
>> }
>>
>> +/**
>> + * bpf_mem_cgroup_vm_events - Read memory cgroup's vm event counter
>> + * @memcg: memory cgroup
>> + * @event: event id
>> + *
>> + * Allows to read memory cgroup event counters.
>> + */
>> +__bpf_kfunc unsigned long bpf_mem_cgroup_vm_events(struct mem_cgroup *memcg,
>> + enum vm_event_item event)
>> +{
>> + return memcg_events(memcg, event);
>> +}
>
> Should this function validate the event parameter before passing it to
> memcg_events()?
>
> The call chain bpf_mem_cgroup_vm_events()->memcg_events()->memcg_events_index()
> reaches an array access in memcg_events_index():
>
> static inline int memcg_events_index(enum vm_event_item idx)
> {
> return mem_cgroup_events_index[idx];
> }
>
> The array mem_cgroup_events_index is declared with size NR_VM_EVENT_ITEMS.
> If a BPF program passes an event value >= NR_VM_EVENT_ITEMS, this would
> cause an out-of-bounds array read.
>
> For comparison, bpf_mem_cgroup_page_state() below validates its idx
> parameter before calling memcg_page_state_output(). A similar check here
> would prevent the potential out-of-bounds access:
>
> if (event < 0 || event >= NR_VM_EVENT_ITEMS)
> return (unsigned long)-1;
No, it's a false positive, as explained in a reply to the similar comment
to v1.
Powered by blists - more mailing lists