linux-kernel - Re: [syzbot] [ntfs?] WARNING in do_open

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 19 Aug 2023 15:16:38 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Mateusz Guzik <mjguzik@...il.com>
Cc:     Kees Cook <keescook@...omium.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        syzbot <syzbot+6ec38f7a8db3b3fb1002@...kaller.appspotmail.com>,
        anton@...era.com, brauner@...nel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-ntfs-dev@...ts.sourceforge.net,
        syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: [syzbot] [ntfs?] WARNING in do_open_execat

On Fri, Aug 18, 2023 at 09:12:39PM +0200, Mateusz Guzik wrote:
> 
> The ntfs image used here is intentionally corrupted and the inode at
> hand has a mode of 777 (as in type not specified).
> 
> Then the type check in may_open():
>         switch (inode->i_mode & S_IFMT) {
> 
> fails to match anything.
> ...
> 
> Do other filesystems have provisions to prevent inodes like this from
> getting here?

Well, what ext4 does is that we do a bunch of basic validity checks in
ext4_iget(), and if the inode is bad (for example the type is not
specified), the following gets executed:

	} else {
		ret = -EFSCORRUPTED;
		ext4_error_inode(inode, function, line, 0,
				 "iget: bogus i_mode (%o)", inode->i_mode);
		goto bad_inode;
       ...

bad_inode:
	brelse(iloc.bh);
	iget_failed(inode);
	return ERR_PTR(ret);

iget_failed() takes the inode under construction (returned by
iget_locked), and marks it as a bad/"dead" inode.  So subsequent
attempts to do anything with the inode, including opening it, will
fail at the VFS level, and you never get to the file system's open
function.

The ext4_error_inode() function is reponsible for logging the error,
and if userspace is using fsnotify and are subscribed FS_ERROR,
notifying user space that the file system is corrupted.  Depending on
the file system settings, we may also remount the file system
read-only, or force a panic to reboot the system (so that a failover
backup server can take over), or just log the message and continuing.

       	      	       	      	      	      - Ted