All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Li Jinyue" <jinyue.li@linux.alibaba.com>, bpf@vger.kernel.org
Subject: Re: [PATCH bpf] bpf: Fix soft lockup in fd_array_map_free()
Date: Thu, 12 Nov 2026 12:30:24 +0000	[thread overview]
Message-ID: <sashiko-outbox-211089@kernel.org> (raw)
In-Reply-To: <20261112122015.3356106-1-jinyue.li@linux.alibaba.com>

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] bpf: signed integer overflow in map iterators [1]
--

commit be46454b32f6f3b215fec94602410fee2a07b5c7
Author: Li Jinyue <jinyue.li@linux.alibaba.com>

bpf: Fix soft lockup in fd_array_map_free()

This commit adds a cond_resched() call to the entry check loop in
fd_array_map_free() to avoid soft lockups when freeing maps with a large
number of entries.

> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index 133f189bf6d27..b975ec3c39e57 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -924,8 +924,10 @@ static void fd_array_map_free(struct bpf_map *map)
>  	int i;
>  
>  	/* make sure it's empty */
> -	for (i = 0; i < array->map.max_entries; i++)
> +	for (i = 0; i < array->map.max_entries; i++) {
>  		BUG_ON(array->ptrs[i] != NULL);
> +		cond_resched();
> +	}

[Severity: Critical]
This problem wasn't introduced by this patch, but can i overflow here when
array->map.max_entries exceeds INT_MAX [1]?

Because i is a signed int compared against the unsigned u32 max_entries, a
map created with max_entries > INT_MAX (when bpf_bypass_spec_v1 is
permitted) causes i to wrap to INT_MIN after reaching INT_MAX.  The
unsigned comparison then stays true and array->ptrs[i] indexes memory at a
large negative offset.  The same signed loop counter issue also affects
bpf_array_alloc_percpu(), bpf_array_free_percpu(), and
perf_event_fd_array_release() in this file, where indexing with a negative
i corrupts or reads out-of-bounds memory.  Should i be declared as u32?

[1] https://sashiko.dev/#/bug/linux-4e93eb71-24a1-4040-b74f-c1c6d5ae58c8

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112122015.3356106-1-jinyue.li@linux.alibaba.com?part=1

  reply	other threads:[~2026-11-12 12:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 12:20 [PATCH bpf] bpf: Fix soft lockup in fd_array_map_free() Li Jinyue
2026-11-12 12:30 ` sashiko-bot [this message]
2026-11-12 19:59 ` Alexei Starovoitov

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=sashiko-outbox-211089@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jinyue.li@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.