From nobody Tue Dec 16 22:35:36 2025 Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F250264A77; Fri, 30 May 2025 18:31:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.149.199.84 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748629916; cv=none; b=c173ObSYWH1N6SL1RtrHihWALnBERMsxZoXgYv3MUMd61aQee0DHkJ5kzHaz8yxY6wbOkHSivFz034Z9kHXOmDwIscd4qT7YZ5qs3ZDtDEgGVmO0kI9skD1rRuyyumoCH2NQWnjCZHYalbwy+wOYnrTtNv4486AZb33rEgHWMQQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748629916; c=relaxed/simple; bh=IXcGfRmy+QSLxbIDnuWEMrDh5ssmCdbJQ9iAfYC4dbU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fUQv0ZIvpPunv5WgsPr9/T6Vi3y1t9WdWq7uAVOFOFevb/znffkjq0gDHf+16FOwRGyo9dplsdVQ84IgN/vzCfjIQBkc3WWaaTR1bE/nQ+ttqnllpxM5yUI7kt9gFmqkFRyj9Jqv1P00mSag4ahlmnjWn7dKt0QKMR146yOz6aM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ispras.ru; spf=pass smtp.mailfrom=ispras.ru; dkim=pass (1024-bit key) header.d=ispras.ru header.i=@ispras.ru header.b=d2Xa3M++; arc=none smtp.client-ip=83.149.199.84 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ispras.ru Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ispras.ru header.i=@ispras.ru header.b="d2Xa3M++" Received: from fedora.intra.ispras.ru (unknown [10.10.165.16]) by mail.ispras.ru (Postfix) with ESMTPSA id 1D8B940755EB; Fri, 30 May 2025 18:31:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 1D8B940755EB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1748629912; bh=yf3N76z1AZ6dIBtW7rVAoKXhww6/Z7dw6mR+g/CZJXg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d2Xa3M++ikZHaMDp6rKgXYOCySkUY8jrjt5AUS/L1g3TwNnMsW9ndUV8ELIJQwc1G HhFGIjRnnx2z6Of1Im4cPL2zisr/UdjfbVQMzPEQdNvMQXco4WdMG8Z0YwVec2rsSn +JUYBhlu1ixQDhqZ9VFMYWeEmVRDRtMEPKt6VUFg= From: Fedor Pchelkin To: Richard Weinberger Cc: Fedor Pchelkin , Zhihao Cheng , David Woodhouse , Wang Yong , Lu Zhongjun , Yang Tao , Al Viro , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org, stable@vger.kernel.org Subject: [PATCH resend 1/2] jffs2: initialize filesystem-private inode info in ->alloc_inode callback Date: Fri, 30 May 2025 21:31:38 +0300 Message-ID: <20250530183141.222155-2-pchelkin@ispras.ru> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250530183141.222155-1-pchelkin@ispras.ru> References: <20250530183141.222155-1-pchelkin@ispras.ru> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The symlink body (->target) should be freed at the same time as the inode itself per commit 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal"). It is a filesystem-specific field but there exist several error paths during generic inode allocation when ->free_inode(), namely jffs2_free_inode(), is called with still uninitialized private info. The calltrace looks like: alloc_inode inode_init_always // fails i_callback free_inode jffs2_free_inode // touches uninit ->target field Commit af9a8730ddb6 ("jffs2: Fix potential illegal address access in jffs2_free_inode") approached the observed problem but fixed it only partially. Our local Syzkaller instance is still hitting these kinds of failures. The thing is that jffs2_i_init_once(), where the initialization of f->target has been moved, is called once per slab allocation so it won't be called for the object structure possibly retrieved later from the slab cache for reuse. The practice followed by many other filesystems is to initialize filesystem-private inode contents in the corresponding ->alloc_inode() callbacks. This also allows to drop initialization from jffs2_iget() and jffs2_new_inode() as ->alloc_inode() is called in those places. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Reviewed-by: Zhihao Cheng --- fs/jffs2/fs.c | 2 -- fs/jffs2/super.c | 3 ++- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index d175cccb7c55..85c4b273918f 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -271,7 +271,6 @@ struct inode *jffs2_iget(struct super_block *sb, unsign= ed long ino) f =3D JFFS2_INODE_INFO(inode); c =3D JFFS2_SB_INFO(inode->i_sb); =20 - jffs2_init_inode_info(f); mutex_lock(&f->sem); =20 ret =3D jffs2_do_read_inode(c, f, inode->i_ino, &latest_node); @@ -439,7 +438,6 @@ struct inode *jffs2_new_inode (struct inode *dir_i, umo= de_t mode, struct jffs2_r return ERR_PTR(-ENOMEM); =20 f =3D JFFS2_INODE_INFO(inode); - jffs2_init_inode_info(f); mutex_lock(&f->sem); =20 memset(ri, 0, sizeof(*ri)); diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c index 4545f885c41e..b56ff63357f3 100644 --- a/fs/jffs2/super.c +++ b/fs/jffs2/super.c @@ -42,6 +42,8 @@ static struct inode *jffs2_alloc_inode(struct super_block= *sb) f =3D alloc_inode_sb(sb, jffs2_inode_cachep, GFP_KERNEL); if (!f) return NULL; + + jffs2_init_inode_info(f); return &f->vfs_inode; } =20 @@ -58,7 +60,6 @@ static void jffs2_i_init_once(void *foo) struct jffs2_inode_info *f =3D foo; =20 mutex_init(&f->sem); - f->target =3D NULL; inode_init_once(&f->vfs_inode); } =20 --=20 2.49.0 From nobody Tue Dec 16 22:35:36 2025 Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A4F021CA04; Fri, 30 May 2025 18:31:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.149.199.84 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748629917; cv=none; b=nKfHUs17wLQUUBcQ6W5OQYh4Z/w1bmvjyAIFwHnp9W49+hZ6R58v4dHvNd20A1rzGwXa4k1y2TJXm1hP92pIkVZLpxDYkuugmugi1+yUpZhPT8osPth5b9Wu8CnM3e9UdziG5spvaY2g0CGYXvkmZNauKX/WAXBgt3cclUXvJDU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748629917; c=relaxed/simple; bh=aPPH3O+CHv4ajmf3ZwJW7f8/l7rxbLeOS5vAZZuDKco=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b9blkTCMc4N2dqB9ZX+xz3+yA5qowsj+ivw5X1oWNVHZ1T6sjpMrFjD1HjwBgu67cDWFHJwxWAOn7c7DdY/PeKYdoKNyp/UL1IqHV5ANjM4TnpNZfxnitHtxtwPmIAQZ3pvOYCOqxQdGQ+1VVC/3hOj/veUtSNC10jfFUeoedBI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ispras.ru; spf=pass smtp.mailfrom=ispras.ru; dkim=pass (1024-bit key) header.d=ispras.ru header.i=@ispras.ru header.b=kuVmiOB5; arc=none smtp.client-ip=83.149.199.84 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ispras.ru Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ispras.ru header.i=@ispras.ru header.b="kuVmiOB5" Received: from fedora.intra.ispras.ru (unknown [10.10.165.16]) by mail.ispras.ru (Postfix) with ESMTPSA id E7E3C40755EE; Fri, 30 May 2025 18:31:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru E7E3C40755EE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1748629913; bh=bERoEa5XKHntoKi9+ZBgubnw2CNe9D2SUrhr9k4FjiQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kuVmiOB5FZ2uXvywY+EeN9pG2hB8B4yLt6lOJARSXYcEuZJ921izS0OtO89F7VnT2 ojJRlvdPAb/h9jZbq1r/6fw0+qa/dT/iivWkEoHg6IE1eMJ2PJbbsRD3/9GSY2UKBf i3W1foWChMxbo+2MNMRuiQGEcPODrVLILtoypliI= From: Fedor Pchelkin To: Richard Weinberger Cc: Fedor Pchelkin , Zhihao Cheng , David Woodhouse , Wang Yong , Lu Zhongjun , Yang Tao , Al Viro , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org, stable@vger.kernel.org Subject: [PATCH resend 2/2] jffs2: initialize inocache earlier Date: Fri, 30 May 2025 21:31:39 +0300 Message-ID: <20250530183141.222155-3-pchelkin@ispras.ru> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250530183141.222155-1-pchelkin@ispras.ru> References: <20250530183141.222155-1-pchelkin@ispras.ru> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Inside jffs2_new_inode() there is a small gap when jffs2_init_acl_pre() or jffs2_do_new_inode() may fail e.g. due to a memory allocation error while uninit inocache field is touched upon subsequent inode eviction. general protection fault, probably for non-canonical address 0xdffffc000000= 0005: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 0 PID: 10592 Comm: syz-executor.1 Not tainted 5.10.209-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/= 2014 RIP: 0010:jffs2_xattr_delete_inode+0x35/0x130 fs/jffs2/xattr.c:602 Call Trace: jffs2_do_clear_inode+0x4c/0x570 fs/jffs2/readinode.c:1418 evict+0x281/0x6b0 fs/inode.c:577 iput_final fs/inode.c:1697 [inline] iput.part.0+0x4df/0x6d0 fs/inode.c:1723 iput+0x58/0x80 fs/inode.c:1713 jffs2_new_inode+0xb12/0xdb0 fs/jffs2/fs.c:469 jffs2_create+0x90/0x400 fs/jffs2/dir.c:177 lookup_open.isra.0+0xead/0x1260 fs/namei.c:3169 open_last_lookups fs/namei.c:3239 [inline] path_openat+0x96c/0x2670 fs/namei.c:3428 do_filp_open+0x1a4/0x3f0 fs/namei.c:3458 do_sys_openat2+0x171/0x420 fs/open.c:1186 do_sys_open fs/open.c:1202 [inline] __do_sys_openat fs/open.c:1218 [inline] __se_sys_openat fs/open.c:1213 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1213 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 Initialize the inocache pointer to a NULL value while preparing an inode in jffs2_init_inode_info(). jffs2_xattr_delete_inode() will handle it later just fine. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Reviewed-by: Zhihao Cheng --- fs/jffs2/os-linux.h | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/jffs2/os-linux.h b/fs/jffs2/os-linux.h index 86ab014a349c..39b6565f10c9 100644 --- a/fs/jffs2/os-linux.h +++ b/fs/jffs2/os-linux.h @@ -55,6 +55,7 @@ static inline void jffs2_init_inode_info(struct jffs2_ino= de_info *f) f->metadata =3D NULL; f->dents =3D NULL; f->target =3D NULL; + f->inocache =3D NULL; f->flags =3D 0; f->usercompr =3D 0; } --=20 2.49.0