linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Baokun Li <libaokun1@huawei.com>
Cc: Edward Adam Davis <eadavis@qq.com>,
	syzbot+2c4a3b922a860084cc7f@syzkaller.appspotmail.com,
	adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com, yangerkun <yangerkun@huawei.com>
Subject: Re: [PATCH] ext4: fix WARNING in lock_two_nondirectories
Date: Sun, 24 Dec 2023 21:11:36 -0500	[thread overview]
Message-ID: <20231225021136.GC491196@mit.edu> (raw)
In-Reply-To: <fb653ebf-0225-00b3-df05-6b685a727b41@huawei.com>

On Mon, Dec 25, 2023 at 09:38:51AM +0800, Baokun Li wrote:
> Marking the boot loader inode as a bad inode here is useless,
> EXT4_IGET_BAD allows us to get a bad boot loader inode.
> In my opinion, it doesn't make sense to call lock_two_nondirectories()
> here to determine if the inode is a regular file or not, since the logic
> for dealing with non-regular files comes after the locking, so calling
> lock_two_inodes() directly here will suffice.

This is all very silly, and why I consider this sort of thing pure
syzkaller noise.  It really doesn't protect against any real threat,
and it encourages people to put all sorts of random crud in kernel
code, all in the name of trying to shut up syzbot.

If we *are* going to care about shutting up syzkaller, the right
approach is to simply add a check in swap_inode_boot_loader() which
causes it to call ext4_error() and declare the file system corrupted
if the bootloader inode is not a regular file, and then return
-EFSCORRUPTED.

We don't need to add random hacks to ext4_iget(), or in other places...

   	      	     	    	     - Ted

  parent reply	other threads:[~2023-12-25  2:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-15 13:49 [syzbot] [ext4?] WARNING in lock_two_nondirectories syzbot
2023-12-24 11:53 ` [PATCH] ext4: fix " Edward Adam Davis
2023-12-24 14:13   ` Matthew Wilcox
2023-12-25  1:38   ` Baokun Li
2023-12-25  2:07     ` Al Viro
2023-12-25  2:33       ` Baokun Li
2023-12-25  2:49         ` Theodore Ts'o
2023-12-25  2:56           ` Baokun Li
2023-12-25  2:11     ` Theodore Ts'o [this message]
2023-12-25  2:15       ` Al Viro
2023-12-25  2:46       ` Baokun Li
2024-02-12  0:00 ` [syzbot] [ext4?] " syzbot
2024-02-12 13:28   ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231225021136.GC491196@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=eadavis@qq.com \
    --cc=libaokun1@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+2c4a3b922a860084cc7f@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yangerkun@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).