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

[sparkhuang]

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