From: "David Hildenbrand (Arm)" <david@kernel.org>
To: sparkhuang <huangshaobo3@xiaomi.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <kees@kernel.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
stable@vger.kernel.org
Subject: Re: [PATCH] fork: reset pointer tag of vmapped thread stack before vfree
Date: Fri, 7 Aug 2026 11:27:24 +0200 [thread overview]
Message-ID: <f5af86ba-e724-4b9f-acdb-2445e2ec4b1e@kernel.org> (raw)
In-Reply-To: <20260806123020.90869-1-huangshaobo3@xiaomi.com>
On 8/6/26 14:30, sparkhuang wrote:
> When a thread stack is freed via RCU callback,
> thread_stack_free_rcu() calls vfree(vm_area->addr). In RCU callback
> context (e.g. from rcu_nocb_cb_kthread with BH disabled, or from
> RCU_SOFTIRQ), in_interrupt() returns true, so vfree() routes to
> vfree_atomic().
>
> vfree_atomic() uses the freed memory as llist storage by calling
> llist_add((struct llist_node *)addr, &p->list), which writes 8 bytes
> to the address being freed. With KASAN SW_TAGS enabled,
> vm_area->addr carries a random tag assigned during allocation by
> kasan_unpoison_vmalloc(). If the shadow memory covering this region
> has been set to KASAN_TAG_KERNEL (0xFF) — e.g. by
> kasan_unpoison_task_stack() using task->stack, which was already
> reset to 0xFF by kasan_reset_tag() at allocation time — the shadow
> byte (0xFF) no longer matches the pointer tag on vm_area->addr,
> and the write in llist_add triggers a KASAN invalid-access report:
>
> ==================================================================
> BUG: KASAN: invalid-access in vfree_atomic+0x90/0x150
> Write of size 8 at addr c2ffffc0a8f70000 by task rcuop/7/75
> Pointer tag: [c2], memory tag: [ff]
>
> CPU: 5 UID: 0 PID: 75 Comm: rcuop/7 Tainted: G S W OE
> Hardware name: XiaoMi Xring_o1 UDP PHONE (DT)
> Call trace:
> show_stack+0x18/0x28
> __dump_stack+0x28/0x3c
> dump_stack_lvl+0xac/0xf0
> print_address_description+0x7c/0x25c
> print_report+0x70/0x8c
> kasan_report+0xdc/0x13c
> __hwasan_store8_noabort+0xe8/0xf8
> vfree_atomic+0x90/0x150
> vfree+0x220/0x298
> thread_stack_free_rcu+0x3c/0x4c
> rcu_do_batch+0x308/0xaf0
> rcu_nocb_cb_kthread+0x33c/0x708
> kthread+0x364/0x3cc
> ret_from_fork+0x10/0x20
>
> The buggy address belongs to a 8-page vmalloc region starting at
> 0xc2ffffc0a8f70000 allocated at copy_process+0x1ac/0x12e4
>
> Memory state around the buggy address:
> ffffffc0a8f6ff00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
> >ffffffc0a8f70000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ^
> ffffffc0a8f70100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ==================================================================
Were you able to reproduce this more than once?
Does this relate to CONFIG_KASAN_STACK? Can you share the kernel config?
--
Cheers,
David
next prev parent reply other threads:[~2026-08-07 9:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 12:30 [PATCH] fork: reset pointer tag of vmapped thread stack before vfree sparkhuang
2026-08-06 14:13 ` Lorenzo Stoakes (ARM)
2026-08-07 6:53 ` sparkhuang
2026-08-07 7:56 ` Lorenzo Stoakes (ARM)
2026-08-07 7:57 ` David Hildenbrand (Arm)
2026-08-07 7:58 ` Lorenzo Stoakes (ARM)
2026-08-07 8:00 ` David Hildenbrand (Arm)
2026-08-07 9:27 ` David Hildenbrand (Arm) [this message]
2026-08-07 10:41 ` sparkhuang
2026-08-07 10:47 ` David Hildenbrand (Arm)
2026-08-07 11:20 ` David Hildenbrand (Arm)
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=f5af86ba-e724-4b9f-acdb-2445e2ec4b1e@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=huangshaobo3@xiaomi.com \
--cc=juri.lelli@redhat.com \
--cc=kees@kernel.org \
--cc=kprateek.nayak@amd.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=ryabinin.a.a@gmail.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/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.