From nobody Thu Apr 9 03:28:35 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.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 469632DC32A for ; Wed, 11 Mar 2026 08:18:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.5 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773217099; cv=none; b=CESuvrQW6j6CRf84hms7FSjiu1EG7DWpeX8d4mnItbF65saaiyn0Y5KdykOe0gHpFFW/qt5ZN/yaYeaBTDF6h2hLu9VUQ+yJQITGsknkL3f1fTPmFmeuSQeAMpHv2zs2dKqQW2CJFdpjbV7YlVGxi7yWbo5s1gUiR67ZF0BeMdo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773217099; c=relaxed/simple; bh=KA9un1C1kAaGof0CdqU9ZVlnhJu+EIL+XsgDgAimTmU=; h=Date:From:To:Cc:Subject:Content-Type:MIME-Version:Message-ID; b=KeZninWGrDiBRyIK/eqsCqO6y2XCCcFPrONXOFEUaTZeiqB19j4qkTCb6CgTD7Gwz0Uky+9QBzvNpfoOKj3YHWOXbNZsjTws+RjgPf0zcQrWLKt0rRekXVsVXQj6w3Coyz9qESFeekQezeeluZ77ibdccpzfjnAUORDSQnz14+g= 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=RAL+Um3x; arc=none smtp.client-ip=117.135.210.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="RAL+Um3x" 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=KA9un1C1kAaGof0CdqU9ZVlnhJu+EIL+XsgDgAimTmU=; b=R AL+Um3xpJGbjA276vfCruVxsW1pzvxTH7vk2XBPOzyqs3AdAkxNJ7dT5SluTvhLP wwid92jdRvtm1ELmh6xwpu4GAYqlNdNNMjiCbDbpoW+HjXNAgyaCTls+90DqjSMM 5oKTufdpmc9ujAokoUCbsXDJgBT9bBOGOpn+K3IEdA= Received: from luckd0g$163.com ( [183.205.138.18] ) by ajax-webmail-wmsvr-40-127 (Coremail) ; Wed, 11 Mar 2026 16:17:51 +0800 (CST) Date: Wed, 11 Mar 2026 16:17:51 +0800 (CST) From: "Jianzhou Zhao" To: shaggy@kernel.org, liaoyuanhong@vivo.com, jfs-discussion@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org Subject: KASAN: slab-use-after-free Read in write_special_inodes 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_Qu2cAf6auEgs5yiaYOkfmU4Rhug7UMO3uf8n24JfPJ9wjA/p2yseUUF9NmPf88CwFTuXvxiGfTNO1/ZAU5Bifrwx+fMRoQ7MEEUgmHAtHSzQ9Q== 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: <1e07e041.7151.19cdbf942da.Coremail.luckd0g@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: fygvCgD3_rsvJbFppsl2AA--.39011W X-CM-SenderInfo: poxfyvkqj6il2tof0z/xtbC9g8bpWmxJS8-VQAA3- X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset="utf-8" Subject: [BUG] jfs: KASAN: slab-use-after-free in write_special_inodes Dear Maintainers, We are writing to report a slab use-after-free (UAF) vulnerability discover= ed in the JFS filesystem's unmount path. This bug was found by our custom f= uzzing tool, RacePilot. The UAF is triggered during a failed filesystem mou= nt/unmount sequence where `jfs_put_super()` prematurely frees the `sbi->dir= ect_inode` before flushing the journal, leading to a fatal memory fault in = `write_special_inodes()`. 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: KASAN: slab-use-after-free in write_special_inodes+0x131/0x170 fs/jfs/= jfs_logmgr.c:206 Read of size 8 at addr ffff888013774a38 by task syz-executor/9881 CPU: 0 UID: 0 PID: 9881 Comm: syz-executor Tainted: G L 6.= 18.0-08691-g2061f18ad76e-dirty #43 PREEMPT(full)=20 ... Call Trace: write_special_inodes+0x131/0x170 fs/jfs/jfs_logmgr.c:206 jfs_flush_journal+0x2b8/0x960 fs/jfs/jfs_logmgr.c:1581 jfs_umount+0x17a/0x440 fs/jfs/jfs_umount.c:58 jfs_put_super+0x85/0x1d0 fs/jfs/super.c:194 generic_shutdown_super+0x156/0x390 fs/super.c:643 kill_block_super+0x3b/0x90 fs/super.c:1730 deactivate_locked_super+0xbf/0x1a0 fs/super.c:474 ... Allocated by task 45171: jfs_fill_super+0xd1/0x1030 fs/jfs/super.c:452 get_tree_bdev_flags+0x389/0x620 fs/super.c:1699 vfs_get_tree+0x93/0x340 fs/super.c:1759 ... Freed by task 38650: kfree+0x2ca/0x6d0 mm/slub.c:6871 generic_shutdown_super+0x156/0x390 fs/super.c:643 kill_block_super+0x3b/0x90 fs/super.c:1730 ... =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 When a `jfs` unmount occurs (or a failed mount aborts causing `jfs_put_supe= r`), the kernel invokes `jfs_umount()` dynamically: ```c // fs/jfs/super.c static void jfs_put_super(struct super_block *sb) { struct jfs_sb_info *sbi =3D JFS_SBI(sb); int rc; jfs_info("In jfs_put_super"); jfs_quota_off_umount(sb); rc =3D jfs_umount(sb); if (rc) jfs_err("jfs_umount failed with return code %d", rc); unload_nls(sbi->nls_tab); truncate_inode_pages(sbi->direct_inode->i_mapping, 0); iput(sbi->direct_inode); kfree(sbi); } ``` The unmount phase eventually flushes the filesystem journal synchronously t= o finalize out-of-band I/O transactions: ```c // fs/jfs/jfs_umount.c int jfs_umount(struct super_block *sb) { ... if ((log =3D sbi->log)) /* * Wait for outstanding transactions to be written to log: */ jfs_flush_journal(log, 2); ... ``` However, inside `jfs_flush_journal()`, the backend logger tries iterating o= ver special filesystem mappings linked inside the `jfs_sb_info` layout: ```c // fs/jfs/jfs_logmgr.c static void write_special_inodes(struct jfs_log *log, int (*writer)(struct address_space *)) { struct jfs_sb_info *sbi; list_for_each_entry(sbi, &log->sb_list, log_list) { writer(sbi->ipbmap->i_mapping); writer(sbi->ipimap->i_mapping); writer(sbi->direct_inode->i_mapping); // <-- KASAN triggers Use-After-Fre= e exception here } } ``` Root Cause Analysis A KASAN Slab Use-After-Free bug emerges inside `write_special_inodes()`. Wh= en the VFS abstraction invokes `generic_shutdown_super`, `jfs_put_super()` = functions cleanly unless the backend volume drops early cache invalidation = during fault teardowns. During normal `jfs_put_super`, `jfs_umount` complet= es, `sbi->direct_inode` is cleaned up via `iput(sbi->direct_inode)` and mem= ory structures begin breaking down. However, if `sbi` was inherently tied into multi-mount sharing the same ext= ernal `jfs_log` subsystem globally, then parallel actions flushing the same= global journal execute `jfs_flush_journal()`. Because `list_for_each_entry= (&log->sb_list)` navigates all bound superblocks attached to the log withou= t strictly validating memory states, it hits the currently-degraded `sbi` a= rray belonging to the tearing-down mount, improperly accessing `sbi->direct= _inode->i_mapping` while the slab memory allocation (`kfree` for `sbi`) has= already dissolved. Unfortunately, we were unable to generate a reproducer for this bug. Potential Impact This logic discrepancy causes highly-privileged local kernel execution faul= ts (DoS), triggering uncorrectable system-wide panics impacting standard na= mespace isolation security if external journals fall out-of-sync against mo= unting/unmounting devices sequentially. Proposed Fix To mitigate this lifecycle lapse, the unmounting superblock (`sbi`) must be= cleanly detached from the `log->sb_list` before any `jfs_flush_journal` ca= lls or before structural freeing transpires in `jfs_put_super()` to ensure = the log processing ignores dangling bounds: ```diff --- a/fs/jfs/jfs_umount.c +++ b/fs/jfs/jfs_umount.c @@ -107,6 +107,11 @@ int jfs_umount(struct super_block *sb) if (log) { /* log =3D NULL if read-only mount */ updateSuper(sb, FM_CLEAN); =20 + /* Remove from log list before flushing residual */ + mutex_lock(&jfs_log_mutex); + list_del_init(&sbi->log_list); + mutex_unlock(&jfs_log_mutex); + /* * close log: * ``` We would be highly honored if this could be of any help. Best regards, RacePilot Team