BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: chenyuan_fl@163.com
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 1/3] bpf, arena: fix range_tree_clear inconsistency on kmalloc_nolock failure
Date: Thu, 06 Aug 2026 03:14:55 +0000	[thread overview]
Message-ID: <20260806031455.E06D31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806030359.299480-2-chenyuan_fl@163.com>

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

Pre-existing issues:
- [High] `range_tree_set()` suffers from the exact same partial-modification flaw that the patch fixes in `range_tree_clear()`, leading to permanent arena slot leaks.
--

--- Patch [1]: [PATCH bpf-next v1 1/3] bpf, arena: fix range_tree_clear inconsistency on kmalloc_nolock failure ---
commit 8092890527e00050d54d5c7b5deedf81e64396d7
Author: Yuan Chen <chenyuan@kylinos.cn>

bpf, arena: fix range_tree_clear inconsistency on kmalloc_nolock failure

This patch addresses an inconsistency in range_tree_clear() where memory
allocation failures could leave the range tree partially modified. It fixes
this by pre-allocating the required node before altering the tree structure.

> diff --git a/kernel/bpf/range_tree.c b/kernel/bpf/range_tree.c
> index 2f28886f3ff75..24fa32d4356bb 100644
> --- a/kernel/bpf/range_tree.c
> +++ b/kernel/bpf/range_tree.c
> @@ -143,16 +143,21 @@ int range_tree_clear(struct range_tree *rt, u32 start, u32 len)
>  		if (rn->rn_start < start && rn->rn_last > last) {
>  			u32 old_last = rn->rn_last;
>  
> +			/* Pre-allocate the right-half node before modifying
> +			 * the tree. If allocation fails we return -ENOMEM
> +			 * without altering the range tree.
> +			 */
> +			new_rn = kmalloc_nolock(sizeof(struct range_node),
> +						__GFP_ACCOUNT, NUMA_NO_NODE);
> +			if (!new_rn)
> +				return -ENOMEM;
> +
>  			/* Overlaps with the entire clearing range */
>  			range_it_remove(rn, rt);

[Severity: High]
This isn't a bug introduced by this patch, but does range_tree_set()
suffer from the exact same partial-modification flaw?

Looking at range_tree_set() in kernel/bpf/range_tree.c, it also modifies the
tree before attempting an allocation:

	/* Clear out everything in the range we want to set. */
	err = range_tree_clear(rt, start, len);
	if (err)
		return err;
...
	} else {
		left = kmalloc_nolock(sizeof(struct range_node), __GFP_ACCOUNT, NUMA_NO_NODE);
		if (!left)
			return -ENOMEM;

If kmalloc_nolock() fails here, the function returns -ENOMEM but leaves the
tree with the overlapping nodes already deleted by range_tree_clear(). Any
previously free sub-ranges that were cleared could be permanently lost.

Furthermore, in kernel/bpf/arena.c, arena_free_pages() appears to ignore the
return value entirely:

	range_tree_set(&arena->rt, pgoff, page_cnt);

Could an allocation failure here result in a silent, permanent leak of arena
virtual address space?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806030359.299480-1-chenyuan_fl@163.com?part=1

  reply	other threads:[~2026-08-06  3:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06  3:03 [PATCH bpf-next v1 0/3] bpf, arena: keep range tree consistent on kmalloc_nolock failure chenyuan_fl
2026-08-06  3:03 ` [PATCH bpf-next v1 1/3] bpf, arena: fix range_tree_clear inconsistency " chenyuan_fl
2026-08-06  3:14   ` sashiko-bot [this message]
2026-08-06  3:03 ` [PATCH bpf-next v1 2/3] bpf, arena: fix range_tree_set " chenyuan_fl
2026-08-06  3:03 ` [PATCH bpf-next v1 3/3] bpf, arena: check range_tree_set return in arena_free_pages and arena_free_worker chenyuan_fl
2026-08-06  3:19   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260806031455.E06D31F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=chenyuan_fl@163.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox