Re: [PATCH] HID: bpf: add __counted_by_ptr attribute to device_data

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] hid-bpf: false-positive bounds check panic via data race in __hid_bpf_allocate_data()
--

commit 4a962db9c72042e7d956ca752f9439fb64fe5e37
Author: Bill Wendling <morbo@google.com>

HID: bpf: add __counted_by_ptr attribute to device_data

The 'struct hid_bpf' contains a 'device_data' pointer field and an
'allocated_data' field that specifies the size in bytes. This commit
adds the '__counted_by_ptr' attribute to 'device_data' to enable bounds
checking sanitizers.

> diff --git a/include/linux/hid_bpf.h b/include/linux/hid_bpf.h
> index 19fffa4574a47..f45fb9cccece8 100644
> --- a/include/linux/hid_bpf.h
> +++ b/include/linux/hid_bpf.h
> @@ -185,10 +185,12 @@ struct hid_bpf_ops {
>  
>  /* stored in each device */
>  struct hid_bpf {
> -	u8 *device_data;		/* allocated when a bpf program of type
> -					 * SEC(f.../hid_bpf_device_event) has been attached
> -					 * to this HID device
> -					 */
> +	/*
> +	 * allocated when a bpf program of type
> +	 * SEC(f.../hid_bpf_device_event) has been attached
> +	 * to this HID device
> +	 */
> +	u8 *device_data __counted_by_ptr(allocated_data);

[Severity: High]
Does this newly added attribute introduce a false-positive bounds check panic?

The commit message mentions that allocated_data is always set before any
access, but looking at __hid_bpf_allocate_data() in 
drivers/hid/bpf/hid_bpf_dispatch.c, it appears the pointer is assigned before 
the count without memory barriers:

	*data = alloc_data;
	*size = alloc_size;

Concurrently, if an incoming HID report triggers 
dispatch_hid_bpf_device_event() (which holds driver_input_lock but not 
prog_list_lock), could it observe a non-NULL device_data pointer while the 
allocated_data count still evaluates to 0?

If so, would the new __counted_by_ptr() attribute cause sanitizers to evaluate
the buffer size as 0 while device_data is active, triggering a false-positive
kernel panic when memcpy(ctx_kern.data, data, *size) is called?

>  	u32 allocated_data;
>  	bool destroyed;			/* prevents the assignment of any progs */
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923063114.2683575-1-morbo@google.com?part=1