linux-kernel - Re: [PATCH (REPOST)] jfs: Verify inode mode when loading from disk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250912150555.GI1587915@frogsfrogsfrogs>
Date: Fri, 12 Sep 2025 08:05:55 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Christian Brauner <brauner@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Dave Kleikamp <shaggy@...nel.org>,
	jfs-discussion@...ts.sourceforge.net
Subject: Re: [PATCH (REPOST)] jfs: Verify inode mode when loading from disk

On Fri, Sep 12, 2025 at 11:18:44PM +0900, Tetsuo Handa wrote:
> The inode mode loaded from corrupted disk can be invalid. Do like what
> commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk")
> does.
> 
> Reported-by: syzbot <syzbot+895c23f6917da440ed0d@...kaller.appspotmail.com>
> Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
> Signed-off-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> ---
> This fix is similar to fixes for other filesystems, but got no response.
> Do we have to wait for Ack from Dave Kleikamp for another month?

Let's hope not, this is a validation issue...

>  fs/jfs/inode.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/jfs/inode.c b/fs/jfs/inode.c
> index fcedeb514e14..21f3d029da7d 100644
> --- a/fs/jfs/inode.c
> +++ b/fs/jfs/inode.c
> @@ -59,9 +59,15 @@ struct inode *jfs_iget(struct super_block *sb, unsigned long ino)
>  			 */
>  			inode->i_link[inode->i_size] = '\0';
>  		}
> -	} else {
> +	} else if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode) ||
> +		   S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode)) {
>  		inode->i_op = &jfs_file_inode_operations;
>  		init_special_inode(inode, inode->i_mode, inode->i_rdev);
> +	} else {
> +		printk(KERN_DEBUG "JFS: Invalid file type 0%04o for inode %lu.\n",
> +		       inode->i_mode, inode->i_ino);
> +		iget_failed(inode);
> +		return ERR_PTR(-EIO);

...but how about EFSCORRUPTED instead of EIO here?  Several filesystems
(xfs, ext*, erofs, f2fs, fuse, ocfs2, udf) return that for corrupt
metadata.

--D

>  	}
>  	unlock_new_inode(inode);
>  	return inode;
> -- 
> 2.51.0
> 
>