From nobody Thu Apr 9 04:04:19 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2287F3B3889 for ; Wed, 11 Mar 2026 07:57:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.5 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773215881; cv=none; b=rLUOp7s71h+nImYIFImJoJDtK8WYOJ8DXZAkXDz+zpwu/qtB+FOAR29lKzKab6jKmuoOL0SjKQPgXk6SblFAeK2A6R5gZPi3p8nhsKVrwfpdohxoT8XsilJeGJIw4MgC2GlvLsf5Hw5fbtdEjBX2VJNyzlyTNkhB23AoR7l8GuE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773215881; c=relaxed/simple; bh=bawSj7Dr+mTR6YHh3H9BIl9zhtuB0cvtdmZfue64MA8=; h=Date:From:To:Subject:Content-Type:MIME-Version:Message-ID; b=AF0UGfenls91n01hhrUInZpImGcaf+4SRZJlN0whj2aQXF+vCY3qc8zmw9jVv0O9OnjWdNJVD99WeoJE8SMSooZbxXCPsQB/XSM1WSw+6YlObXw1d50VIU5+XcLKHE2MUW2KMA3nPJoYRttJT8YP6Jh8SQsdYJDlcbSszjsszr4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=TAw/MwOA; arc=none smtp.client-ip=220.197.31.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="TAw/MwOA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:To:Subject:Content-Type:MIME-Version: Message-ID; bh=bawSj7Dr+mTR6YHh3H9BIl9zhtuB0cvtdmZfue64MA8=; b=T Aw/MwOAI+nTiWmhVLQRqPwu0Tf5a/ju1KYuRGl9GBD04u+n6aPnMrOh2/TsVsDnR NbHl50Lu/gOo0I01MmyghkwOAdS2VUqVNu74Tx78JxaSQjprUb0OhY1xSn/bZics q6hWHqrjpBjoVB0hONuBRUSEsI05ZZoF84tJPJU0yQ= Received: from luckd0g$163.com ( [183.205.138.18] ) by ajax-webmail-wmsvr-40-127 (Coremail) ; Wed, 11 Mar 2026 15:57:24 +0800 (CST) Date: Wed, 11 Mar 2026 15:57:24 +0800 (CST) From: "Jianzhou Zhao" To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, aliceryhl@google.com, Liam.Howlett@oracle.com, andrewjballance@gmail.com, maple-tree@lists.infradead.org Subject: KCSAN: data-race in mas_topiary_replace / mtree_range_walk X-Priority: 3 X-Mailer: Coremail Webmail Server Version 2023.4-cmXT build 20251222(83accb85) Copyright (c) 2002-2026 www.mailtech.cn 163com X-NTES-SC: AL_Qu2cAf6aukAv4iKbZukfmU4Rhug7UMO3uf8n24JfPJ9wjA/p2yseUUF9NmPf88CwFTuXvxiGfTNO1/ZAU5BifrwxUsl4+P2LdD+uDjkWUQe+RQ== Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <269c0123.6ac9.19cdbe68793.Coremail.luckd0g@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: fygvCgDXf51kILFpwsB2AA--.25766W X-CM-SenderInfo: poxfyvkqj6il2tof0z/xtbC9gTncmmxIGTVUwAA39 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset="utf-8" Subject: [BUG] lib/maple_tree: KCSAN: data-race in mas_topiary_replace / mt= ree_range_walk Dear Maintainers, We are writing to report a KCSAN-detected data race vulnerability within `l= ib/maple_tree.c`. This bug was found by our custom fuzzing tool, RacePilot.= The race occurs during the node lifecycle management in the maple tree whe= n `mas_topiary_replace()` (via `mte_set_node_dead()`) marks a block as dead= by modifying `node->parent` using a plain write, while a concurrent RCU-pr= otected walker in `mtree_range_walk()` evaluates node death via `ma_dead_no= de()` performing an unannotated read on the exact same `node->parent` varia= ble. We observed this bug on the Linux kernel version 6.18.0-08691-g2061f18= ad76e-dirty. Call Trace & Context =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KCSAN: data-race in mas_topiary_replace / mtree_range_walk write to 0xffff88800c9f3e00 of 8 bytes by task 43414 on cpu 1: mte_set_node_dead home/kfuzz/linux/lib/maple_tree.c:335 [inline] mas_put_in_tree home/kfuzz/linux/lib/maple_tree.c:1571 [inline] mas_topiary_replace+0x14e/0x14a0 home/kfuzz/linux/lib/maple_tree.c:2350 mas_wmb_replace home/kfuzz/linux/lib/maple_tree.c:2443 [inline] mas_split home/kfuzz/linux/lib/maple_tree.c:3067 [inline] mas_commit_b_node home/kfuzz/linux/lib/maple_tree.c:3087 [inline] mas_wr_bnode+0xd2a/0x23b0 home/kfuzz/linux/lib/maple_tree.c:3755 mas_wr_store_entry+0x77b/0x1120 home/kfuzz/linux/lib/maple_tree.c:3787 mas_store_prealloc+0x47c/0xa60 home/kfuzz/linux/lib/maple_tree.c:5191 ... __x64_sys_mmap+0x71/0xa0 home/kfuzz/linux/arch/x86/kernel/sys_x86_64.c:82 read to 0xffff88800c9f3e00 of 8 bytes by task 43413 on cpu 0: ma_dead_node home/kfuzz/linux/lib/maple_tree.c:576 [inline] mtree_range_walk+0x11e/0x630 home/kfuzz/linux/lib/maple_tree.c:2594 mas_state_walk home/kfuzz/linux/lib/maple_tree.c:3313 [inline] mas_walk+0x2a4/0x400 home/kfuzz/linux/lib/maple_tree.c:4617 lock_vma_under_rcu+0xd3/0x710 home/kfuzz/linux/mm/mmap_lock.c:238 do_user_addr_fault home/kfuzz/linux/arch/x86/mm/fault.c:1327 [inline] handle_page_fault home/kfuzz/linux/arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x294/0x10d0 home/kfuzz/linux/arch/x86/mm/fault.c:1532 ... value changed: 0xffff8880330fec41 -> 0xffff88800c9f3e00 Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 43413 Comm: syz.0.3576 Not tainted 6.18.0-08691-g2061f18= ad76e-dirty #42 PREEMPT(voluntary)=20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/= 2014 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Execution Flow & Code Context The race involves marking maple tree nodes as obsolete against concurrent R= CU readers. During VMA map modifications (like `sys_mmap`), writers invoke = `mas_wr_store_entry()` mapping modifications that frequently necessitate tr= ee node splitting. A split triggers replacing obsolete topiary structures i= n `mas_topiary_replace()`, which terminates old nodes by pointing their par= ent links cyclically to themselves in `mte_set_node_dead()`: ```c // lib/maple_tree.c static inline void mte_set_node_dead(struct maple_enode *mn) { mte_to_node(mn)->parent =3D ma_parent_ptr(mte_to_node(mn)); // <-- Plain c= oncurrent write smp_wmb(); /* Needed for RCU */ } ``` Meanwhile, a concurrent page fault (`do_user_addr_fault`) can acquire the r= ead-lock locklessly using `lock_vma_under_rcu`, walking the maple tree stat= es via `mtree_range_walk()`. Within this walk, readers validate the nodes t= hey jump onto aren't dead by inspecting the cyclic relationship through `ma= _dead_node()`: ```c // lib/maple_tree.c static __always_inline bool ma_dead_node(const struct maple_node *node) { struct maple_node *parent; /* Do not reorder reads from the node prior to the parent check */ smp_rmb(); parent =3D (void *)((unsigned long)node->parent & ~MAPLE_NODE_MASK); // <-= - Plain concurrent read return (parent =3D=3D node); } ``` Root Cause Analysis A KCSAN data race arises because one thread assigns the node's topological = state pointer `node->parent` during topiary teardowns while another lockles= s RCU thread inspects `node->parent` synchronously but without memory safet= y compiler directives (`READ_ONCE`/`WRITE_ONCE`). Since the reader depends = on `smp_rmb()` to coordinate the access sequence but fails to assert volati= le instructions strictly, the C compiler maintains the leeway to perform op= timizations or load tearing on the pointer assignment. Unfortunately, we were unable to generate a reproducer for this bug. Potential Impact This data race technically compromises the RCU safety protocol on certain a= ggressive compiler topologies. Read tearing or asynchronous propagation ove= r the parent cyclic relationship check during `lock_vma_under_rcu` could yi= eld unhandled page faults bypassing tree structure mapping lookups. This tr= anslates to transient denial-of-service conditions mapping virtual memory p= ages under high threading contention. Proposed Fix To correct this concurrency violation and adhere strictly to the Linux Kern= el Memory Model, `WRITE_ONCE` must be used in `mte_set_node_dead()` when te= rminating the parental link, and conversely, `READ_ONCE` in `ma_dead_node()= ` must capture the pointer snapshot safely against racing cyclic mutations. ```diff --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -332,7 +332,7 @@ static inline struct maple_node *mas_mn(const struct ma= _state *mas) static inline void mte_set_node_dead(struct maple_enode *mn) { - mte_to_node(mn)->parent =3D ma_parent_ptr(mte_to_node(mn)); + WRITE_ONCE(mte_to_node(mn)->parent, ma_parent_ptr(mte_to_node(mn))); smp_wmb(); /* Needed for RCU */ } =20 @@ -579,7 +579,7 @@ static __always_inline bool ma_dead_node(const struct m= aple_node *node) { struct maple_node *parent; =20 /* Do not reorder reads from the node prior to the parent check */ smp_rmb(); - parent =3D (void *)((unsigned long)node->parent & ~MAPLE_NODE_MASK); + parent =3D (void *)((unsigned long)READ_ONCE(node->parent) & ~MAPLE_NODE_= MASK); return (parent =3D=3D node); } ``` We would be highly honored if this could be of any help. Best regards, RacePilot Team