Re: [PATCH] fork: reset pointer tag of vmapped thread stack before vfree

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

I'm sorry that whole reply is more AI slop and I'm not reading it.

I have zero interest in chatting to an LLM via a middle man.

On Fri, Aug 07, 2026 at 02:53:51PM +0800, sparkhuang wrote:
> Hi Lorenzo,
>
> Thanks for the review. You're right on the process points ??? I'll fold
> those into a v2 (real name, Assisted-by: tag, drop Cc: stable, trim the
> comment, correct the Fixes: target). I won't re-spin it just yet though,
> for the reason below.
>
> I want to be upfront about where the analysis actually stands, because
> I'd rather not push a fix whose rationale I can't fully back up.
>
> The one-line change itself is sound and follows existing precedent:
> c08e6a1206e6 already resets tsk->stack to 0xFF, and 528a4ab45300 does
> the same in scs_free(). A 0xFF-tagged pointer bypasses the KASAN tag
> check, so vfree_atomic()'s llist_add write to the freed region stops
> faulting regardless of what the memory tag currently holds. That makes
> the reported false positive go away ??? that part I'm confident in.
>
> What I have *not* nailed down is why "memory tag: [ff]" shows up in the
> report in the first place. On the 6.18 android-common tree:
>
>   - At allocation __kasan_unpoison_vmalloc() tags vm_area->addr with a
>     random tag (0xc2 here) and sets the backing memory tag to the same
>     0xc2, so they match at that point ??? the report is not from the
>     alloc path.
>   - c08e6a1206e6 resets tsk->stack to 0xFF (SP can't be tagged); its
>     commit message explicitly notes the stack *memory* still gets tagged.
>   - The only caller of kasan_unpoison_task_stack() ??? which would write a
>     0xFF tag into the backing memory ??? is the idle-task path in
>     kernel/cpu.c. It is not called for normal task stacks, so my earlier
>     commit-message attribution to that function was wrong.
>   - page_kasan_tag_reset() only touches page->flags metadata, not the
>     physical memory tag, so that's not the source either.
>
> So what flips the memory tag from 0xc2 to 0xFF between allocation and
> the RCU callback remains an open question. My suspicion is the async
> vfree_atomic / delayed_vfree + page-reuse interplay during the reboot
> SIGTERM storm (the trace also shows page flags kasantag=0x55, a third
> value inconsistent with both), but I haven't proven a specific path.
>
> Accordingly I don't have a deterministic reproducer. The report is
> reproducible only in the sense that it shows up during reboot with heavy
> thread churn; I haven't been able to trigger it on demand.
>
> Given that, I'd like to hold v2 until the 0xFF source is understood
> rather than ship a commit message that hand-waves the root cause. If you
> or the KASAN folks have a view on whether the reset_tag fix is acceptable
> as a "stops the false positive, mirrors existing precedent" change
> without a fully root-caused explanation ??? versus waiting ??? I'd
> appreciate the steer.
>
> Best,
> Shaobo

--
Cheers, Lorenzo