From nobody Mon Feb 9 12:31:35 2026 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 02B2F1DB366; Sun, 17 Nov 2024 18:44:36 +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=1731869080; cv=none; b=ItMU0BHnNVLRLAhWyMBRT2q0R7q3jBFPuJnMPvaZIzg8IiPzY22eYjIhK1N+SXvMbeBkYYT8raJtZ+I4VmnxIk2MebD9ju9XOlwkM1I9DaLYn0P/5iII1JvAMK5W7HfLdGspAOZFhCpt9CEBpLlZuRbvt0ct2z9FLwTiwk9VjfY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731869080; c=relaxed/simple; bh=xQww0AHembV1GDwFeMLbSDN+DhisvJ75fpAxcYvS27I=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=MwwrNahVYzDfgJMfbT88sIK+fmzpSLn60SdosMUc25GV6UdlPRK4vXk09Uhvan+Ed6Cf6jBWIKAHCsEe3RLStAdTJyxBaDOh3qPF3++18N2rIAvAK2K0hKM7Sbikuuhx+hEcoMcguJbkJOiwcJTYRHLwzk8JUK6V+fOvWUL4jTI= 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=K7IzjkwP; 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="K7IzjkwP" Received: from fpc.intra.ispras.ru (unknown [10.10.165.6]) by mail.ispras.ru (Postfix) with ESMTPSA id 8F1D1518E779; Sun, 17 Nov 2024 18:44:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 8F1D1518E779 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1731869068; bh=UizkzJsqxuNwf5Xw9wKym3zKbiu8RngTlGJwvHGM9ME=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K7IzjkwP0LkE4kjgTpXFIHbAU72yRgqEC4jjxSmLHo0f6Q0NPCTTxlUecgl371fV+ qWvCGH+D72kmrt+iXhHtvzqAaMIkPRsDGE3jlqqPDJwhHvlYrwkh8dlQFvemSFOoyT QcuWRgSIUhAOUkQfdsytKRrprCvz3uc69ANyGm8s= From: Fedor Pchelkin To: Richard Weinberger , Zhihao Cheng Cc: Fedor Pchelkin , 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 1/2] jffs2: initialize filesystem-private inode info in ->alloc_inode callback Date: Sun, 17 Nov 2024 21:44:11 +0300 Message-Id: <20241117184412.366672-2-pchelkin@ispras.ru> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241117184412.366672-1-pchelkin@ispras.ru> References: <20241117184412.366672-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.39.5 From nobody Mon Feb 9 12:31:35 2026 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 044691DB372; Sun, 17 Nov 2024 18:44:36 +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=1731869079; cv=none; b=osWBsOVtTozHvMkWYKCaG+SqQqNp9xbDSnSYhJesMz5ATjeqgSk60A3UzbIOIZzKS6WbwZ4dhPKmQQh2S71K2yPAhBqLR/oQMdPdJ+/ZXzMjFqocHlx+ZodpJ4QmIamDObayCTnwOO2EkSAoLmmyX7zDgrAhjRrohphShbyl+c0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731869079; c=relaxed/simple; bh=mF5mAl1yefvIXyEEzISzCNTuGTrDa/onIGRCa/o2AqY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=EDSh9tJq3d/jqmFA0p+CBoZGirRJoiAgJOUb0AL55pERj0rp2dML/wS1/hw2RxBol/p8Bk8o2ZMXiNy64Ftn1WDn5+6xkTo5MiK29YAZJWawqJdoGxMv14UtpW6DfYpfThFuMkQfKHrK5Gh1w9M/kogSIR4KHFKjEDoKj4WksoQ= 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=ifWoM0aZ; 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="ifWoM0aZ" Received: from fpc.intra.ispras.ru (unknown [10.10.165.6]) by mail.ispras.ru (Postfix) with ESMTPSA id 574F6518E77B; Sun, 17 Nov 2024 18:44:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 574F6518E77B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1731869069; bh=z83vOsND3dmU2lQdMai5FHCaNYTMGUxXC+d3JRYKOAM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ifWoM0aZW9jsM3hf2l0UNIgHM7DMOleLcyN4dOwzuyjuCzoFHRjMqXvAnVy7G/Q2S IoMbsXVH1VCcctIrAMdgjHVWJwSp8ggJq2XeTpvTxa2Wz25ePntE0gOLPrZ6JjeFPo G5z22+bEsjoKLwZv1tVQ+O6OnpLAT83KqBiSlf5I= From: Fedor Pchelkin To: Richard Weinberger , Zhihao Cheng Cc: Fedor Pchelkin , 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 2/2] jffs2: initialize inocache earlier Date: Sun, 17 Nov 2024 21:44:12 +0300 Message-Id: <20241117184412.366672-3-pchelkin@ispras.ru> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241117184412.366672-1-pchelkin@ispras.ru> References: <20241117184412.366672-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.39.5