Re: [PATCH] uprobes: Use flexible array for xol_area bitmap

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Calling kfree() on a flexible array member triggers an invalid free, leading to kernel panic or slab corruption.
--

commit 2653ad1e88bfeb53b361b9c646fc5e888019afa9
Author: Rosen Penev <rosenp@gmail.com>

uprobes: Use flexible array for xol_area bitmap

This commit converts the xol_area bitmap from a separately allocated
pointer to a flexible array member. It also updates the allocation to
use kzalloc_flex() and removes the associated error handling in
__create_xol_area().

> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 4084e926e2844..9ef74c2ad3907 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -108,7 +108,6 @@ static LIST_HEAD(delayed_uprobe_list);
>   */
>  struct xol_area {
>  	wait_queue_head_t		wq;		/* if all slots are busy */
> -	unsigned long			*bitmap;	/* 0 = free slot */
>  
>  	struct page			*page;
>  	/*
> @@ -117,6 +116,7 @@ struct xol_area {
>  	 * the vma go away, and we must handle that reasonably gracefully.
>  	 */
>  	unsigned long			vaddr;		/* Page(s) of instruction slots */
> +	unsigned long			bitmap[];	/* 0 = free slot */
>  };

Does this conversion leave a stale kfree() in uprobe_clear_state()?

Since bitmap is now a flexible array member, area->bitmap evaluates to an
interior address within the xol_area slab object.

Looking at uprobe_clear_state(), the kfree() is still present:

kernel/events/uprobes.c:uprobe_clear_state() {
...
	if (!area)
		return;

	put_page(area->page);
	kfree(area->bitmap);
	kfree(area);
}

Could this lead to slab corruption or a kernel panic when a process with a
registered uprobe is terminated, since we are passing an interior pointer to
kfree()?

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