From nobody Thu Apr 9 04:04:20 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) (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 0548A37702D for ; Wed, 11 Mar 2026 07:59:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773215977; cv=none; b=KdavydtzSuz434ocXJLfWd3+ynop4q/UDW/MehzfAkzERbRKWBMOyl3OPJr0/GLaqmdm09FAMPLNsHS/VrmFTavt5MAYPM9wNmiTzPCdRL8+uBeUKcIegIXUICjXtGvPwHurhtmpaWfWIqDFkSeKDWIWXawjrVVwQVL6fEv6Y50= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773215977; c=relaxed/simple; bh=0YiAcAXrlUy/GCM8H1IaXXD7uF4euM1CcQTkXvWyop0=; h=Date:From:To:Subject:Content-Type:MIME-Version:Message-ID; b=IqRMLPQxyMiWiAFIx47GpYitk3SUrTe47v3FFdAPNjDa9yXMtbay+b6JsyeRnDHNbueFc1MRjLm5b/pMnlEIp67nevKkMu/aqyHM6jMrOtREaClmcgZhUbdR7j8vePY1nxm+Fzr13KYpFVpDM1y7TyNiTT0BdtEt4iFKveeuqpE= 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=CjhogH7r; arc=none smtp.client-ip=117.135.210.2 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="CjhogH7r" 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=0YiAcAXrlUy/GCM8H1IaXXD7uF4euM1CcQTkXvWyop0=; b=C jhogH7rjU4rmb4YcyhL23taH1NMy9YPYy9y47nYCKOz6YYm7ehS+aNq1ctA+qFIu EcNZqY0kKrk7L0NbxjkDAbYMb5oaQP0QBAFMewnHer4l7sMSqZRDSti8DQ3N48tD 0tj2OvWT2JcxOBI+YjqxTLCi/7DfZesYKdrfWSM/5A= Received: from luckd0g$163.com ( [183.205.138.18] ) by ajax-webmail-wmsvr-40-127 (Coremail) ; Wed, 11 Mar 2026 15:58:55 +0800 (CST) Date: Wed, 11 Mar 2026 15:58:55 +0800 (CST) From: "Jianzhou Zhao" To: pfalcato@suse.de, akpm@linux-foundation.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: BUG: KCSAN: data-race in do_mremap / vma_complete 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_Qu2cAf6aukEo4yKYY+kfmU4Rhug7UMO3uf8n24JfPJ9wjA/p2yseUUF9NmPf88CwFTuXvxiGfTNO1/ZAU5BifrwxtnJfSAt/wE4bfhBSt5bTNw== 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: <1a7d4c26.6b46.19cdbe7eaf0.Coremail.luckd0g@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: fygvCgBXU7G_ILFpcMF2AA--.25454W X-CM-SenderInfo: poxfyvkqj6il2tof0z/xtbC9h-9iGmxIL-cIgAA3l X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset="utf-8" Subject: [BUG] mm/mremap: KCSAN: data-race in do_mremap / vma_complete Dear Maintainers, We are writing to report a KCSAN-detected data race vulnerability within th= e memory management subsystem, specifically involving `vma_complete` and `c= heck_mremap_params`. This bug was found by our custom fuzzing tool, RacePil= ot. The race occurs when `vma_complete` increments the `mm->map_count` conc= urrently while `check_mremap_params` evaluates the same `current->mm->map_c= ount` without holding the appropriate `mmap_lock` or using atomic snapshot = primitives (`READ_ONCE`). We observed this bug on the Linux kernel version = 6.18.0-08691-g2061f18ad76e-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 do_mremap / vma_complete write to 0xffff88800c232348 of 4 bytes by task 27920 on cpu 1: =C2=A0vma_complete+0x6d2/0x8a0 home/kfuzz/linux/mm/vma.c:354 =C2=A0__split_vma+0x5fb/0x6f0 home/kfuzz/linux/mm/vma.c:567 =C2=A0vms_gather_munmap_vmas+0xe5/0x6a0 home/kfuzz/linux/mm/vma.c:1369 =C2=A0do_vmi_align_munmap+0x2a3/0x450 home/kfuzz/linux/mm/vma.c:1538 =C2=A0do_vmi_munmap+0x19c/0x2e0 home/kfuzz/linux/mm/vma.c:1596 =C2=A0do_munmap+0x97/0xc0 home/kfuzz/linux/mm/mmap.c:1068 =C2=A0mremap_to+0x179/0x240 home/kfuzz/linux/mm/mremap.c:1374 =C2=A0... =C2=A0__x64_sys_mremap+0x66/0x80 home/kfuzz/linux/mm/mremap.c:1961 read to 0xffff88800c232348 of 4 bytes by task 27919 on cpu 0: =C2=A0check_mremap_params home/kfuzz/linux/mm/mremap.c:1816 [inline] =C2=A0do_mremap+0x352/0x1090 home/kfuzz/linux/mm/mremap.c:1920 =C2=A0__do_sys_mremap+0x129/0x160 home/kfuzz/linux/mm/mremap.c:1993 =C2=A0__se_sys_mremap home/kfuzz/linux/mm/mremap.c:1961 [inline] =C2=A0__x64_sys_mremap+0x66/0x80 home/kfuzz/linux/mm/mremap.c:1961 =C2=A0... value changed: 0x0000001f -> 0x00000020 Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 27919 Comm: syz.7.1375 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 In `mm/vma.c`, the `vma_complete()` function finalizes VMA alterations such= as insertions. When a new VMA is successfully attached (e.g., during split= ting), the function increments the process's `map_count` while holding the = necessary `mmap_lock` in write mode from the calling context: ```c // mm/vma.c static void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi, =C2=A0 =C2=A0 struct mm_struct *mm) { =C2=A0... =C2=A0} else if (vp->insert) { =C2=A0 /* ... split ... */ =C2=A0 vma_iter_store_new(vmi, vp->insert); =C2=A0 mm->map_count++; // <-- Plain concurrent write =C2=A0} =C2=A0... } ``` Conversely, the `mremap` syscall validation sequence preemptively evaluates= `check_mremap_params()` *before* acquiring the `mmap_lock`. This allows dr= opping malformed syscalls fast but leaves the map quota check unsynchronize= d: ```c // mm/mremap.c static unsigned long check_mremap_params(struct vma_remap_struct *vrm) { =C2=A0... =C2=A0/* Worst-scenario case ... */ =C2=A0if ((current->mm->map_count + 2) >=3D sysctl_max_map_count - 3) // <-= - Plain concurrent read =C2=A0 return -ENOMEM; =C2=A0return 0; } ``` At `mm/mremap.c:1924`, the `mmap_write_lock_killable(mm)` is only acquired = *after* `check_mremap_params()` successfully returns. Root Cause Analysis A KCSAN data race arises because the `mremap` parameters validator attempts= to enact an early heuristic rejection based on the current threshold of `m= m->map_count`. However, this evaluation executes entirely without locks (`m= map_lock` is taken subsequently in `do_mremap`). This establishes a plain, = lockless read racing against concurrent threads legitimately mutating `mm->= map_count` (such as `vma_complete` splitting areas and incrementing the cou= nt under the protection of `mmap_lock`). The lack of `READ_ONCE()` combined= with a mutating operation provokes the KCSAN alarm and potentially permits= compiler load shearing. Unfortunately, we were unable to generate a reproducer for this bug. Potential Impact This data race technically threatens the deterministic outcome of the `mrem= ap` heuristic limit guard. Because `map_count` spans 4 bytes, severe compil= er load tearing across cache lines theoretically could trick `check_mremap_= params` into accepting or rejecting expansions erratically. Functionally, a= s a heuristic pre-check, it is virtually benign since a stricter bounded ev= aluation takes place later under safety locks, but fixing it stops sanitizi= ng infrastructure exhaustion and formalizes the lockless memory access. Proposed Fix To inform the compiler and memory models that the read access of `map_count= ` inside `check_mremap_params` deliberately operates locklessly, we should = wrap the evaluation using the `data_race()` macro to suppress KCSAN warning= s effectively while conveying intent. ```diff Suggested-by: Jianzhou Zhao --- a/mm/mremap.c +++ b/mm/mremap.c @@ -1813,7 +1813,7 @@ static unsigned long check_mremap_params(struct vma_r= emap_struct *vrm) =C2=A0 =C2=A0* Check whether current map count plus 2 still leads us to 4 m= aps below =C2=A0 =C2=A0* the threshold, otherwise return -ENOMEM here to be more safe. =C2=A0 =C2=A0*/ - if ((current->mm->map_count + 2) >=3D sysctl_max_map_count - 3) + if ((data_race(current->mm->map_count) + 2) >=3D sysctl_max_map_count - 3) =C2=A0 =C2=A0return -ENOMEM; =C2=A0 return 0; ``` We would be highly honored if this could be of any help. Best regards, RacePilot Team =20