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: <20241113040415.GF1458936@google.com> Date: Wed, 13 Nov 2024 13:04:15 +0900 From: Sergey Senozhatsky <senozhatsky@...omium.org> To: Theodore Ts'o <tytso@....edu> Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, Andreas Dilger <adilger.kernel@...ger.ca>, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: ext4: possible circular locking dependency at ext4_xattr_inode_create Hi Ted, On (24/11/12 10:29), Theodore Ts'o wrote: > > I've a following syzkaller report (no reproducer); the report is > > against 5.15, but the same call-chain seems possible in current > > upstream as well. So I suspect that maybe ext4_xattr_inode_create() > > should take nested inode_lock (I_MUTEX_XATTR) instead. Does the > > patch below make any sense? > > These syzkaller reports result from mounting a corrupted (fuzzed) file > system typically when an inode is used in multiple contexts (e.g., as > a directory and an EA inode, etc.) at the same time. I certainly see your point, and I don't argue. > I'd have to take a closer look to see if it makes sense, but in > general, very often whenever we try to fix one of these it ends up > triggering some other syzkaller failure. I see, the one-liner that I posted sort of looks like an addition to d1bc560e9a9c7 which landed in ext4 recently. > And, these sorts of things don't actually result in actual security > problems (at worst, a hang / denial of service attack), and the right > thing to do is to just run fsck on the !@...? file system before > mounting the thing. So in our particular case reboot is a bad scenario. Looking at reports from the fleet I see a bunch of hung-task reboots with ext4 frames, e.g. ext4_update_i_disksize()->down_write()->schedule() /* forever */, but I can't claim that this is the deadlock that syzkaller has reported, it very well might not be.
Powered by blists - more mailing lists