From nobody Thu Apr 9 04:09:30 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 C10693AF66A for ; Wed, 11 Mar 2026 07:38:29 +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=1773214718; cv=none; b=kuYtIyBWNGwu78VSl6w7rg83D/j9rCkibqPI9lhPoU8qy5wBhPScJJ3qN550xxc9LeOqYqqvHNIxPkCF4dnOJU5YUucp6NGkBLWe2s+uUy5DpJ2a2/hsHA5bJplUemVTKEwowyU2HK2SEVVVOg2GrWq0DGO+fSqgWLXXaqsdSgQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773214718; c=relaxed/simple; bh=dLJyWKu9JbWplIu3AldxLYjcG4gLOqQVlh2r8vnDz2I=; h=Date:From:To:Subject:Content-Type:MIME-Version:Message-ID; b=XwHepTOFouC0JjvlfD0UnLp8nYzpJ36PeIF/9VGVrOVG853mo63NfeHnpbnF0h1c/bfp5SSCOhGlr+zgMiv5hDrhq7syzapt0Ui7nTV2zhlo/WEzrhJ2vcWO59ICbCKxbBbWFatXdYDQXv2GW6cKJyu604/B4u55cbmsWBOhAKA= 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=bbuHiceM; 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="bbuHiceM" 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=dLJyWKu9JbWplIu3AldxLYjcG4gLOqQVlh2r8vnDz2I=; b=b buHiceMMQXx5eo4kXO97FFwTMCXrfUFoC8uSzpad22WtUbMHk87kcd+1xwI6qCbe yJ17j7SJIzRYNK1t5NdgwC0Dn1LnYarM+QvEH6HoJbzPRCRKMYlhiTP0VHqCNJVn 5ktrt65EKVrEWHNzFonO9lZYj6lt72WWD/bm9I0gQo= Received: from luckd0g$163.com ( [183.205.138.18] ) by ajax-webmail-wmsvr-40-127 (Coremail) ; Wed, 11 Mar 2026 15:36:47 +0800 (CST) Date: Wed, 11 Mar 2026 15:36:47 +0800 (CST) From: "Jianzhou Zhao" To: linux-kernel@vger.kernel.org, senozhatsky@chromium.org, pmladek@suse.com, rostedt@goodmis.org, andriy.shevchenko@linux.intel.com, linux@rasmusvillemoes.dk, akpm@linux-foundation.org Subject: KCSAN: data-race in data_push_tail / symbol_string 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_Qu2cAf6au04r4SedbekfmU4Rhug7UMO3uf8n24JfPJ9wjA/p2yseUUF9NmPf88CwFTuXvxiGfTNO1/ZAU5Bifrwx7pRxwkxvX2IvsNk8RAxUKg== 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: <4a692712.648a.19cdbd3a995.Coremail.luckd0g@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: fygvCgDnT5GPG7FpDrh2AA--.38780W X-CM-SenderInfo: poxfyvkqj6il2tof0z/xtbC9g+wO2mxG49z2wAA3W X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset="utf-8" Subject: [BUG] printk: KCSAN: data-race in data_push_tail / symbol_string Dear Maintainers, We are writing to report a KCSAN-detected data-race vulnerability in the Li= nux kernel. This bug was found by our custom fuzzing tool, RacePilot. The b= ug occurs during ringbuffer tail advancement where a reader speculatively r= eads the `blk->id` from a physical address that has concurrently been overw= ritten by a writer formatting a string. We observed this on the Linux kerne= l 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 data_push_tail.part.0 / symbol_string write to 0xffffffff88f194a8 of 1 bytes by task 38579 on cpu 0: string_nocheck lib/vsprintf.c:658 [inline] symbol_string+0x129/0x2c0 lib/vsprintf.c:1020 pointer+0x24c/0x920 lib/vsprintf.c:2565 vsnprintf+0x5d0/0xb80 lib/vsprintf.c:2982 vscnprintf+0x41/0x90 lib/vsprintf.c:3042 printk_sprint+0x31/0x1c0 kernel/printk/printk.c:2199 vprintk_store+0x3f6/0x980 kernel/printk/printk.c:2321 vprintk_emit+0xfd/0x540 kernel/printk/printk.c:2412 vprintk_default+0x26/0x30 kernel/printk/printk.c:2451 vprintk+0x1d/0x30 kernel/printk/printk_safe.c:82 _printk+0x63/0x90 kernel/printk/printk.c:2461 printk_stack_address arch/x86/kernel/dumpstack.c:70 [inline] __show_trace_log_lvl+0x1ed/0x370 arch/x86/kernel/dumpstack.c:282 __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xb0/0xe0 lib/dump_stack.c:120 dump_stack+0x15/0x20 lib/dump_stack.c:129 fail_dump lib/fault-inject.c:73 [inline] should_fail_ex+0x26b/0x280 lib/fault-inject.c:174 should_fail_alloc_page+0x108/0x130 mm/fail_page_alloc.c:44 prepare_alloc_pages mm/page_alloc.c:4953 [inline] __alloc_frozen_pages_noprof+0x24d/0x1120 mm/page_alloc.c:5172 alloc_pages_mpol+0x90/0x280 mm/mempolicy.c:2416 folio_alloc_mpol_noprof mm/mempolicy.c:2435 [inline] vma_alloc_folio_noprof+0xa0/0x170 mm/mempolicy.c:2470 folio_prealloc mm/memory.c:1207 [inline] alloc_anon_folio mm/memory.c:5175 [inline] do_anonymous_page mm/memory.c:5232 [inline] do_pte_missing mm/memory.c:4402 [inline] handle_pte_fault mm/memory.c:6287 [inline] __handle_mm_fault+0xf1d/0x21f0 mm/memory.c:6421 handle_mm_fault+0x2ee/0x820 mm/memory.c:6590 do_user_addr_fault arch/x86/mm/fault.c:1336 [inline] handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x398/0x10d0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618 read to 0xffffffff88f194a8 of 8 bytes by task 38521 on cpu 1: data_make_reusable kernel/printk/printk_ringbuffer.c:606 [inline] data_push_tail.part.0+0xe6/0x350 kernel/printk/printk_ringbuffer.c:692 data_push_tail kernel/printk/printk_ringbuffer.c:656 [inline] data_alloc+0x157/0x330 kernel/printk/printk_ringbuffer.c:1096 prb_reserve+0x44d/0x7d0 kernel/printk/printk_ringbuffer.c:1742 vprintk_store+0x3b4/0x980 kernel/printk/printk.c:2311 vprintk_emit+0xfd/0x540 kernel/printk/printk.c:2412 vprintk_default+0x26/0x30 kernel/printk/printk.c:2451 vprintk+0x1d/0x30 kernel/printk/printk_safe.c:82 _printk+0x63/0x90 kernel/printk/printk.c:2461 _fat_msg+0x91/0xc0 fs/fat/misc.c:62 __fat_fs_error+0x185/0x1b0 fs/fat/misc.c:31 fat_bmap_cluster fs/fat/cache.c:303 [inline] fat_get_mapped_cluster+0x255/0x260 fs/fat/cache.c:320 fat_bmap+0x14c/0x280 fs/fat/cache.c:384 __fat_get_block fs/fat/inode.c:132 [inline] fat_get_block+0xa3/0x550 fs/fat/inode.c:194 block_read_full_folio+0x17b/0x480 fs/buffer.c:2461 do_mpage_readpage+0x1bf/0xc80 fs/mpage.c:314 mpage_read_folio+0xc5/0x130 fs/mpage.c:395 fat_read_folio+0x1c/0x30 fs/fat/inode.c:209 filemap_read_folio+0x2b/0x160 mm/filemap.c:2523 filemap_update_page mm/filemap.c:2610 [inline] filemap_get_pages+0xcef/0x10a0 mm/filemap.c:2741 filemap_read+0x248/0x7e0 mm/filemap.c:2828 generic_file_read_iter+0x1d0/0x240 mm/filemap.c:3019 __kernel_read+0x33a/0x6a0 fs/read_write.c:541 kernel_read+0xb0/0x180 fs/read_write.c:559 prepare_binprm fs/exec.c:1608 [inline] search_binary_handler fs/exec.c:1655 [inline] exec_binprm fs/exec.c:1701 [inline] bprm_execve fs/exec.c:1753 [inline] bprm_execve+0x510/0xae0 fs/exec.c:1729 do_execveat_common.isra.0+0x2bd/0x3f0 fs/exec.c:1859 do_execveat fs/exec.c:1944 [inline] __do_sys_execveat fs/exec.c:2018 [inline] __se_sys_execveat fs/exec.c:2012 [inline] __x64_sys_execveat+0x78/0x90 fs/exec.c:2012 x64_sys_call+0x1ee4/0x2030 arch/x86/include/generated/asm/syscalls_64.h:323 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xae/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000fffff47a -> 0x302f303978302b6c Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 38521 Comm: syz.7.1998 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 On CPU 0, a printing task formats an output string containing a symbol addr= ess through `vsprintf.c` which recursively formats data and writes to a buf= fer natively byte-by-byte: ```c // lib/vsprintf.c static char *string_nocheck(char *buf, char *end, const char *s, struct printf_spec spec) { ... while (lim--) { char c =3D *s++; ... if (buf < end) *buf =3D c; // <-- Plain Write ++buf; ... } return widen_string(buf, len, end, spec); } ``` This destination buffer represents the text block inside the physical `prin= tk_ringbuffer` array, historically mapped out by `data_alloc()`. Concurrent= ly, CPU 1 calls `prb_reserve()` advancing `data_make_reusable()` along the = same space to check if it's safe to clear descriptors. The reader uses `blk= ->id` unannotated to see if a particular logical block was recycled: ```c // kernel/printk/printk_ringbuffer.c static bool data_make_reusable(struct printk_ringbuffer *rb, ...) { ... while (need_more_space(data_ring, lpos_begin, lpos_end)) { blk =3D to_block(data_ring, lpos_begin); /* * Load the block ID from the data block. This is a data race * against a writer that may have newly reserved this data * area. If the loaded value matches a valid descriptor ID, ... */ id =3D blk->id; /* LMM(data_make_reusable:A) */ // <-- Plain Lockless Re= ad ... ``` Root Cause Analysis A data race occurs because the reader speculatively accesses `blk->id` usin= g a plain memory access (`id =3D blk->id`). However, because another concur= rent task (`CPU 0`) running `vsprintf` has already pushed the logical bound= aries on this data array and is linearly formatting strings onto this exact= overlapping physical memory region block, `CPU 1` reads data undergoing ch= aracter writes. This is an intentional heuristic documented by the comment:= "This is a data race against a writer that may have newly reserved this da= ta area". Reading garbage here is gracefully handled out-of-band by mapping= the `sys_desc` ring ID and concluding it mismatching. However, it still tr= ips compiler sanitizer checks. Unfortunately, we were unable to generate a reproducer for this bug. Potential Impact This data race is functionally benign. If `data_make_reusable` reads format= ted text characters rather than a proper `unsigned long id`, it safely skip= s it and verifies limits via `blk_lpos` logic. However, tripping the KCSAN = sanitizer adds unnecessary debugging noise and may hide actual vulnerabilit= ies under prolonged workloads. Proposed Fix To silence the compiler sanitizer and explicitly annotate to the memory mod= el that this deliberate racing behavior is expected, `data_race()` macro sh= ould wrap the read on `blk->id`. ```diff --- a/kernel/printk/printk_ringbuffer.c +++ b/kernel/printk/printk_ringbuffer.c @@ -616,7 +616,7 @@ static bool data_make_reusable(struct printk_ringbuffer= *rb, * sure it points back to this data block. If the check fails, * the data area has been recycled by another writer. */ - id =3D blk->id; /* LMM(data_make_reusable:A) */ + id =3D data_race(blk->id); /* LMM(data_make_reusable:A) */ =20 d_state =3D desc_read(desc_ring, id, &desc, NULL, NULL); /* LMM(data_make_reusable:B) */ ``` We would be highly honored if this could be of any help. Best regards, RacePilot Team