From: Catalin Marinas <catalin.marinas@arm.com>
To: Reda CHERKAOUI <redacherkaoui67@gmail.com>
Cc: will@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] arm64/mm: harden ASID allocator against empty bitmap after rollover
Date: Tue, 10 Mar 2026 17:24:42 +0000 [thread overview]
Message-ID: <abBT2gV84-9uaHkJ@arm.com> (raw)
In-Reply-To: <20260219113715.8001-1-redacherkaoui67@gmail.com>
On Thu, Feb 19, 2026 at 11:37:14AM +0000, Reda CHERKAOUI wrote:
> new_context() assumes that after incrementing asid_generation and calling
> flush_context(), find_next_zero_bit() will always find a free ASID.
>
> If that invariant is ever violated, __set_bit(NUM_USER_ASIDS, asid_map)
> would write past the end of the bitmap. Add a defensive check so the
> kernel fails loudly instead of silently corrupting memory.
> Cc: stable@vger.kernel.org
>
> Signed-off-by: Reda CHERKAOUI <redacherkaoui67@gmail.com>
> ---
> arch/arm64/mm/context.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
> index b2ac06246327..74c1ece7db78 100644
> --- a/arch/arm64/mm/context.c
> +++ b/arch/arm64/mm/context.c
> @@ -160,6 +160,7 @@ static u64 new_context(struct mm_struct *mm)
> static u32 cur_idx = 1;
> u64 asid = atomic64_read(&mm->context.id);
> u64 generation = atomic64_read(&asid_generation);
> + unsigned long idx;
>
> if (asid != 0) {
> u64 newasid = asid2ctxid(ctxid2asid(asid), generation);
> @@ -194,9 +195,11 @@ static u64 new_context(struct mm_struct *mm)
> * a reserved TTBR0 for the init_mm and we allocate ASIDs in even/odd
> * pairs.
> */
> - asid = find_next_zero_bit(asid_map, NUM_USER_ASIDS, cur_idx);
> - if (asid != NUM_USER_ASIDS)
> + idx = find_next_zero_bit(asid_map, NUM_USER_ASIDS, cur_idx);
> + if (idx != NUM_USER_ASIDS) {
> + asid = idx;
> goto set_asid;
> + }
>
> /* We're out of ASIDs, so increment the global generation count */
> generation = atomic64_add_return_relaxed(ASID_FIRST_VERSION,
> @@ -204,7 +207,10 @@ static u64 new_context(struct mm_struct *mm)
> flush_context();
>
> /* We have more ASIDs than CPUs, so this will always succeed */
> - asid = find_next_zero_bit(asid_map, NUM_USER_ASIDS, 1);
> + idx = find_next_zero_bit(asid_map, NUM_USER_ASIDS, 1);
> + if (unlikely(idx == NUM_USER_ASIDS))
> + panic("ASID allocator: no free ASIDs after rollover\n");
> + asid = idx;
How do you even hit this? Is it if you have less ASIDs than the number
of CPUs? The kernel complains about this in asids_update_limit.
Anyway, given how you are not following up on maintainer's comments, I
assume these patches are automatically generated.
--
Catalin
prev parent reply other threads:[~2026-03-10 17:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 11:37 [PATCH] arm64/mm: harden ASID allocator against empty bitmap after rollover Reda CHERKAOUI
2026-03-10 17:24 ` Catalin Marinas [this message]
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=abBT2gV84-9uaHkJ@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=redacherkaoui67@gmail.com \
--cc=stable@vger.kernel.org \
--cc=will@kernel.org \
/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.