Re: [RFC bpf-next 2/3] bpf: implement compare-and-delete (BPF_F_COMPARE) for BPF_MAP_TYPE_HASH

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] BPF_MAP_DELETE_ELEM no longer validates that the `value` field is zero, silently allowing uninitialized garbage and breaking BPF's strict UAPI zero-initialization guarantees.
--

commit 513ae67888e0e87d8de22021be59f6117444ee43
Author: Gyutae Bae <gyutae.bae@navercorp.com>

bpf: implement compare-and-delete (BPF_F_COMPARE) for BPF_MAP_TYPE_HASH

This commit introduces the BPF_F_COMPARE flag for map_delete_elem(), allowing
atomic compare-and-delete operations on hash maps. It adds a new map operation
and updates the syscall handler to process the new compare fields.

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
[ ... ]
> @@ -1892,18 +1892,30 @@ static int map_update_elem(union bpf_attr *attr, bpfptr_t uattr)
>  	return err;
>  }
>  
> -#define BPF_MAP_DELETE_ELEM_LAST_FIELD key
> +#define BPF_MAP_DELETE_ELEM_LAST_FIELD compare_size
>  
>  static int map_delete_elem(union bpf_attr *attr, bpfptr_t uattr)
>  {
>  	bpfptr_t ukey = make_bpfptr(attr->key, uattr.is_kernel);
>  	struct bpf_map *map;
> -	void *key;
> +	void *key, *compare = NULL;
> +	u32 off = 0, size = 0;
>  	int err;
>  
>  	if (CHECK_ATTR(BPF_MAP_DELETE_ELEM))
>  		return -EINVAL;
>  
> +	if (attr->flags & ~BPF_F_COMPARE)
> +		return -EINVAL;
> +
> +	/* The compare* fields are meaningful only with BPF_F_COMPARE.  Reject them
> +	 * when the flag is absent so a dropped BPF_F_COMPARE cannot silently turn a
> +	 * compare-and-delete into an unconditional delete.
> +	 */
> +	if (!(attr->flags & BPF_F_COMPARE) &&
> +	    (attr->compare || attr->compare_offset || attr->compare_size))
> +		return -EINVAL;

[Severity: High]
Does changing BPF_MAP_DELETE_ELEM_LAST_FIELD to compare_size bypass
zero-validation for attr->value?

CHECK_ATTR now only validates that fields after compare_size are zero.
The patch manually adds validation for flags and the compare* fields to ensure
they are zero when not in use, but it does not appear to add a similar check
for attr->value.

Could this allow userspace to pass uninitialized stack garbage in the value
field without being rejected, permanently preventing the safe repurposing of
the value field for future BPF_MAP_DELETE_ELEM extensions?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622071649.31541-1-gyutae.opensource@navercorp.com?part=2