[PATCH bpf-next v1 0/2] Fix leftover issues of the unify bpf_call_arg_meta patchset

[PATCH bpf-next v1 0/2] Fix leftover issues of the unify bpf_call_arg_meta patchset

[Amery Hung]

Hi,

This patchset fixes preexisting issues flagged by Sashiko when reviewing
the patchset unifying bpf_call_arg_meta [0].

[0] https://lore.kernel.org/bpf/20260715064047.1793790-1-ameryhung@gmail.com/

Amery Hung (2):
  bpf: Disable raw mdoe for bloom filter map_peek
  bpf: Zero kfunc arg meta before error paths can read it

 kernel/bpf/verifier.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

-- 
2.52.0

[PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek

[Amery Hung]

For a bloom filter, the value argument of bpf_map_peek_elem() is always
an input. Therefore, the verifier should not allow passing uninitialized
stack memory to it to avoid information leak.

bpf_map_peek_elem() tags its value argument ARG_PTR_TO_MAP_VALUE |
MEM_UNINIT, telling the verifier the callee fills the buffer. This holds
for queue/stack maps, but not for a bloom filter, which reads the buffer
as an input to test set membership and never writes it.

As a result, a program can pass an uninitialized stack buffer to
bpf_map_peek_elem() on a bloom filter. The verifier accepts it and marks
the buffer initialized on return, letting the program read back leftover
kernel stack memory. Bloom maps require CAP_BPF to create, so this is a
CAP_BPF-gated stack infoleak that bypasses the boundary CAP_BPF is meant
to enforce (arbitrary kernel reads are gated behind CAP_PERFMON).

Signed-off-by: Amery Hung <ameryhung@gmail.com>
---
 kernel/bpf/verifier.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index de816063ae63..c87e5fec5a85 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -8422,6 +8422,15 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
 			verifier_bug(env, "invalid map_ptr to access map->value");
 			return -EFAULT;
 		}
+
+		/*
+		 * Disable raw mode for bpf_map_peek_elem() on a bloom filter. The helper reads
+		 * the value buffer as an input rather than filling it.
+		 */
+		if (meta->func_id == BPF_FUNC_map_peek_elem &&
+		    meta->map.ptr->map_type == BPF_MAP_TYPE_BLOOM_FILTER)
+			meta->arg_raw_mem.regno = 0;
+
 		err = check_helper_mem_access(env, reg, argno, meta->map.ptr->value_size,
 					      arg_type & MEM_WRITE ? BPF_WRITE : BPF_READ,
 					      false, meta);
-- 
2.52.0

[PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it

[Amery Hung]

check_kfunc_call() reads meta.func_name when bpf_fetch_kfunc_arg_meta()
returns -EACCES, but that error can come from fetch_kfunc_meta() (e.g.
fd_array_get_btf() rejecting BTF binding for a signed program) before
meta is memset(), leaving it uninitialized and risking a garbage deref
in verbose().

Move the memset() to the start of bpf_fetch_kfunc_arg_meta() so meta is
zeroed on every error return. The intended "not allowed" -EACCES path
still sets func_name first, so its message is unchanged.

Signed-off-by: Amery Hung <ameryhung@gmail.com>
---
 kernel/bpf/verifier.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index c87e5fec5a85..ddfa4f57016b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -12571,11 +12571,12 @@ int bpf_fetch_kfunc_arg_meta(struct bpf_verifier_env *env,
 	struct bpf_kfunc_meta kfunc;
 	int err;
 
+	memset(meta, 0, sizeof(*meta));
+
 	err = fetch_kfunc_meta(env, func_id, offset, &kfunc);
 	if (err)
 		return err;
 
-	memset(meta, 0, sizeof(*meta));
 	meta->btf = kfunc.btf;
 	meta->func_id = kfunc.id;
 	meta->func_proto = kfunc.proto;
-- 
2.52.0

Re: [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek

[sashiko-bot]

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

Pre-existing issues:
- [High] bpf_map_pop_elem() and bpf_map_peek_elem() leak uninitialized kernel stack memory on queue and stack maps if the map's spinlock is contended.
--

--- Patch [1]: [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek ---
commit 89de02f623877f9e477f4639136b8a23b2fbbd7c
Author: Amery Hung <ameryhung@gmail.com>

bpf: Disable raw mdoe for bloom filter map_peek

This commit prevents an information leak by disabling raw mode for
bpf_map_peek_elem() when used with a bloom filter. It notes that unlike
queue or stack maps, bloom filters use the value buffer as an input and
do not fill it.

> bpf: Disable raw mdoe for bloom filter map_peek

[Severity: Low]
This isn't a bug, but there is a typo (mdoe) in the commit subject line.

> bpf_map_peek_elem() tags its value argument ARG_PTR_TO_MAP_VALUE |
> MEM_UNINIT, telling the verifier the callee fills the buffer. This holds
> for queue/stack maps, but not for a bloom filter, which reads the buffer
> as an input to test set membership and never writes it.

[Severity: High]
This is a pre-existing issue and was not introduced by this patch, but
since the commit message mentions that the MEM_UNINIT assumption holds for
queue and stack maps, does it hold true if the map's spinlock is contended?

Looking at __queue_map_get() in kernel/bpf/queue_stack_maps.c:

	if (raw_res_spin_lock_irqsave(&qs->lock, flags))
		return -EBUSY;

And similarly in __stack_map_get():

	if (raw_res_spin_lock_irqsave(&qs->lock, flags))
		return -EBUSY;

If the lock fails (e.g. due to deadlock detection), these functions return
-EBUSY immediately without zero-initializing the output memory. Since the
verifier assumes the buffer is initialized due to the MEM_UNINIT tag, could
a BPF program read uninitialized kernel stack memory if bpf_map_pop_elem()
or bpf_map_peek_elem() is called on a queue or stack map and hits this
contention path?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715172127.2416388-1-ameryhung@gmail.com?part=1

Re: [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it

[sashiko-bot]

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

Pre-existing issues:
- [High] BPF kfuncs bpf_mem_cgroup_memory_events and bpf_mem_cgroup_vm_events do not handle negative enum values, bypassing bounds checks and allowing out-of-bounds array reads.
--

--- Patch [2]: [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it ---
commit 53f60dae3990fbb436a03cb878e7564339ccd1e9
Author: Amery Hung <ameryhung@gmail.com>

bpf: Zero kfunc arg meta before error paths can read it

check_kfunc_call() reads meta.func_name when bpf_fetch_kfunc_arg_meta()
returns -EACCES, but that error can come from fetch_kfunc_meta() (e.g.
fd_array_get_btf() rejecting BTF binding for a signed program) before
meta is memset(), leaving it uninitialized and risking a garbage deref
in verbose().

Move the memset() to the start of bpf_fetch_kfunc_arg_meta() so meta is
zeroed on every error return. The intended "not allowed" -EACCES path
still sets func_name first, so its message is unchanged.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index c87e5fec5a857..ddfa4f57016b7 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but this is a pre-existing issue.
Do the bounds checks in bpf_mem_cgroup_memory_events() and
bpf_mem_cgroup_vm_events() properly handle negative values?

Since enums evaluate to signed integers in C, and the BPF verifier does
not enforce enum ranges, a BPF program could pass a negative value to
bpf_mem_cgroup_memory_events() in mm/bpf_memcontrol.c:

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

	return atomic_long_read(&memcg->memory_events[event]);

For a negative value, the bounds check above evaluates to false, which
allows an out-of-bounds read on the memory_events array.

Can a similar out-of-bounds read happen in bpf_mem_cgroup_vm_events()?

	if (unlikely(!memcg_vm_event_item_valid(event)))
		return (unsigned long)-1;

	return memcg_events(memcg, event);

The validation routine in mm/memcontrol.c uses the same signed comparison:

bool memcg_vm_event_item_valid(enum vm_event_item idx)
{
	if (idx >= NR_VM_EVENT_ITEMS)
		return false;

	return !BAD_STAT_IDX(memcg_events_index(idx));
}

This allows negative index values to reach memcg_events_index():

static inline int memcg_events_index(enum vm_event_item idx)
{
	return mem_cgroup_events_index[idx];
}

Could this allow a BPF program to read arbitrary out-of-bounds kernel memory?

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

Re: [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

>     bpf: Zero kfunc arg meta before error paths can read it
>
>     check_kfunc_call() reads meta.func_name when bpf_fetch_kfunc_arg_meta()
>     returns -EACCES, but that error can come from fetch_kfunc_meta() (e.g.
>     fd_array_get_btf() rejecting BTF binding for a signed program) before
>     meta is memset(), leaving it uninitialized and risking a garbage deref
>     in verbose().
>
>     Move the memset() to the start of bpf_fetch_kfunc_arg_meta() so meta is
>     zeroed on every error return. The intended "not allowed" -EACCES path
>     still sets func_name first, so its message is unchanged.
>
>     Signed-off-by: Amery Hung <ameryhung@gmail.com>

This looks like a fix for an uninitialized read introduced when
fetch_kfunc_meta() was added and bpf_fetch_kfunc_arg_meta() was reordered so
the memset() ran after the fetch could return -EACCES.  Should this include a
Fixes: tag?

  Fixes: 08ca87d63243 ("bpf: Introduce struct bpf_kfunc_meta")


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/29436864141

Re: [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

> commit 54799fbcec7677972df927e8da6804b0cd39495d
> Author: Amery Hung <ameryhung@gmail.com>
>
>     bpf: Disable raw mdoe for bloom filter map_peek
>
>     For a bloom filter, the value argument of bpf_map_peek_elem() is always
>     an input. Therefore, the verifier should not allow passing uninitialized
>     stack memory to it to avoid information leak.
>
>     bpf_map_peek_elem() tags its value argument ARG_PTR_TO_MAP_VALUE |
>     MEM_UNINIT, telling the verifier the callee fills the buffer. This holds
>     for queue/stack maps, but not for a bloom filter, which reads the buffer
>     as an input to test set membership and never writes it.
>
>     As a result, a program can pass an uninitialized stack buffer to
>     bpf_map_peek_elem() on a bloom filter. The verifier accepts it and marks
>     the buffer initialized on return, letting the program read back leftover
>     kernel stack memory. Bloom maps require CAP_BPF to create, so this is a
>     CAP_BPF-gated stack infoleak that bypasses the boundary CAP_BPF is meant
>     to enforce (arbitrary kernel reads are gated behind CAP_PERFMON).
>
>     Signed-off-by: Amery Hung <ameryhung@gmail.com>

This looks like a bug fix for the raw mode handling introduced in commit
92ec8b1b6b24. Should this include:

  Fixes: 92ec8b1b6b24 ("bpf: Factor out raw_mode-related fields in bpf_call_arg_meta")


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/29436864141

Re: [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek

[Kumar Kartikeya Dwivedi]

On Wed Jul 15, 2026 at 7:38 PM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] bpf_map_pop_elem() and bpf_map_peek_elem() leak uninitialized kernel stack memory on queue and stack maps if the map's spinlock is contended.
> --
>
> --- Patch [1]: [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek ---
> commit 89de02f623877f9e477f4639136b8a23b2fbbd7c
> Author: Amery Hung <ameryhung@gmail.com>
>
> bpf: Disable raw mdoe for bloom filter map_peek
>
> This commit prevents an information leak by disabling raw mode for
> bpf_map_peek_elem() when used with a bloom filter. It notes that unlike
> queue or stack maps, bloom filters use the value buffer as an input and
> do not fill it.
>
>> bpf: Disable raw mdoe for bloom filter map_peek
>
> [Severity: Low]
> This isn't a bug, but there is a typo (mdoe) in the commit subject line.
>
>> bpf_map_peek_elem() tags its value argument ARG_PTR_TO_MAP_VALUE |
>> MEM_UNINIT, telling the verifier the callee fills the buffer. This holds
>> for queue/stack maps, but not for a bloom filter, which reads the buffer
>> as an input to test set membership and never writes it.
>
> [Severity: High]
> This is a pre-existing issue and was not introduced by this patch, but
> since the commit message mentions that the MEM_UNINIT assumption holds for
> queue and stack maps, does it hold true if the map's spinlock is contended?
>
> Looking at __queue_map_get() in kernel/bpf/queue_stack_maps.c:
>
> 	if (raw_res_spin_lock_irqsave(&qs->lock, flags))
> 		return -EBUSY;
>
> And similarly in __stack_map_get():
>
> 	if (raw_res_spin_lock_irqsave(&qs->lock, flags))
> 		return -EBUSY;
>

We should probably do memset(value, 0, qs->map.value_size) like the case below
in the branch returning -EBUSY.

> If the lock fails (e.g. due to deadlock detection), these functions return
> -EBUSY immediately without zero-initializing the output memory. Since the
> verifier assumes the buffer is initialized due to the MEM_UNINIT tag, could
> a BPF program read uninitialized kernel stack memory if bpf_map_pop_elem()
> or bpf_map_peek_elem() is called on a queue or stack map and hits this
> contention path?

Re: [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it

[Kumar Kartikeya Dwivedi]

On Wed Jul 15, 2026 at 7:21 PM CEST, Amery Hung wrote:
> check_kfunc_call() reads meta.func_name when bpf_fetch_kfunc_arg_meta()
> returns -EACCES, but that error can come from fetch_kfunc_meta() (e.g.
> fd_array_get_btf() rejecting BTF binding for a signed program) before
> meta is memset(), leaving it uninitialized and risking a garbage deref
> in verbose().
>
> Move the memset() to the start of bpf_fetch_kfunc_arg_meta() so meta is
> zeroed on every error return. The intended "not allowed" -EACCES path
> still sets func_name first, so its message is unchanged.
>
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
> ---

Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

Re: [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it

[Kumar Kartikeya Dwivedi]

On Wed Jul 15, 2026 at 7:38 PM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] BPF kfuncs bpf_mem_cgroup_memory_events and bpf_mem_cgroup_vm_events do not handle negative enum values, bypassing bounds checks and allowing out-of-bounds array reads.
> --
>
> --- Patch [2]: [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it ---
> commit 53f60dae3990fbb436a03cb878e7564339ccd1e9
> Author: Amery Hung <ameryhung@gmail.com>
>
> bpf: Zero kfunc arg meta before error paths can read it
>
> check_kfunc_call() reads meta.func_name when bpf_fetch_kfunc_arg_meta()
> returns -EACCES, but that error can come from fetch_kfunc_meta() (e.g.
> fd_array_get_btf() rejecting BTF binding for a signed program) before
> meta is memset(), leaving it uninitialized and risking a garbage deref
> in verbose().
>
> Move the memset() to the start of bpf_fetch_kfunc_arg_meta() so meta is
> zeroed on every error return. The intended "not allowed" -EACCES path
> still sets func_name first, so its message is unchanged.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index c87e5fec5a857..ddfa4f57016b7 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>
> [ ... ]
>
> [Severity: High]
> This isn't a bug introduced by this patch, but this is a pre-existing issue.
> Do the bounds checks in bpf_mem_cgroup_memory_events() and
> bpf_mem_cgroup_vm_events() properly handle negative values?
>
> Since enums evaluate to signed integers in C, and the BPF verifier does
> not enforce enum ranges, a BPF program could pass a negative value to
> bpf_mem_cgroup_memory_events() in mm/bpf_memcontrol.c:
>
> 	if (unlikely(event >= MEMCG_NR_MEMORY_EVENTS))
> 		return (unsigned long)-1;
>
> 	return atomic_long_read(&memcg->memory_events[event]);
>
> For a negative value, the bounds check above evaluates to false, which
> allows an out-of-bounds read on the memory_events array.
>
> Can a similar out-of-bounds read happen in bpf_mem_cgroup_vm_events()?
>
> 	if (unlikely(!memcg_vm_event_item_valid(event)))
> 		return (unsigned long)-1;
>

+Cc Roman

I think we should just do:

	if (unlikely(event < 0 || !memcg_vm_event_item_valid(event)))
 		return (unsigned long)-1;

as fix?

> 	return memcg_events(memcg, event);
>
> The validation routine in mm/memcontrol.c uses the same signed comparison:
>
> bool memcg_vm_event_item_valid(enum vm_event_item idx)
> {
> 	if (idx >= NR_VM_EVENT_ITEMS)
> 		return false;
>
> 	return !BAD_STAT_IDX(memcg_events_index(idx));
> }
>
> This allows negative index values to reach memcg_events_index():
>
> static inline int memcg_events_index(enum vm_event_item idx)
> {
> 	return mem_cgroup_events_index[idx];
> }
>
> Could this allow a BPF program to read arbitrary out-of-bounds kernel memory?

Re: [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek

[Kumar Kartikeya Dwivedi]

On Wed Jul 15, 2026 at 7:21 PM CEST, Amery Hung wrote:
> For a bloom filter, the value argument of bpf_map_peek_elem() is always
> an input. Therefore, the verifier should not allow passing uninitialized
> stack memory to it to avoid information leak.
>
> bpf_map_peek_elem() tags its value argument ARG_PTR_TO_MAP_VALUE |
> MEM_UNINIT, telling the verifier the callee fills the buffer. This holds
> for queue/stack maps, but not for a bloom filter, which reads the buffer
> as an input to test set membership and never writes it.
>
> As a result, a program can pass an uninitialized stack buffer to
> bpf_map_peek_elem() on a bloom filter. The verifier accepts it and marks
> the buffer initialized on return, letting the program read back leftover
> kernel stack memory. Bloom maps require CAP_BPF to create, so this is a
> CAP_BPF-gated stack infoleak that bypasses the boundary CAP_BPF is meant
> to enforce (arbitrary kernel reads are gated behind CAP_PERFMON).
>
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
> ---

Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

>  kernel/bpf/verifier.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index de816063ae63..c87e5fec5a85 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -8422,6 +8422,15 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
>  			verifier_bug(env, "invalid map_ptr to access map->value");
>  			return -EFAULT;
>  		}
> +
> +		/*
> +		 * Disable raw mode for bpf_map_peek_elem() on a bloom filter. The helper reads
> +		 * the value buffer as an input rather than filling it.
> +		 */
> +		if (meta->func_id == BPF_FUNC_map_peek_elem &&
> +		    meta->map.ptr->map_type == BPF_MAP_TYPE_BLOOM_FILTER)
> +			meta->arg_raw_mem.regno = 0;
> +

Sigh. Such unfortunate misuse of semantics.