| 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
| ||
|
Message-ID: <20231225021544.GF1674809@ZenIV> Date: Mon, 25 Dec 2023 02:15:44 +0000 From: Al Viro <viro@...iv.linux.org.uk> To: Theodore Ts'o <tytso@....edu> Cc: Baokun Li <libaokun1@...wei.com>, Edward Adam Davis <eadavis@...com>, syzbot+2c4a3b922a860084cc7f@...kaller.appspotmail.com, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com, yangerkun <yangerkun@...wei.com> Subject: Re: [PATCH] ext4: fix WARNING in lock_two_nondirectories On Sun, Dec 24, 2023 at 09:11:36PM -0500, Theodore Ts'o wrote: > 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... Just check the inode type before anything else and be done with that - if an in-core inode of a regular file manages to become a directory right under us, we have a much worse problem. IOW, the bug is real, but suggested patch is just plain wrong.
Powered by blists - more mailing lists