| 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: <tencent_C97469775766D83D6D366E966236D24AB409@qq.com>
Date: Fri, 6 Dec 2024 21:13:57 +0800
From: Edward Adam Davis <eadavis@...com>
To: konishi.ryusuke@...il.com
Cc: eadavis@...com,
linux-kernel@...r.kernel.org,
linux-nilfs@...r.kernel.org,
syzbot+9260555647a5132edd48@...kaller.appspotmail.com,
syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] nilfs2: drop the inode which has been removed
On Fri, 6 Dec 2024 01:04:23 +0900, Ryusuke Konishi wrote:
> > syzbot reported a WARNING in nilfs_rmdir. [1]
> >
> > The inode is used twice by the same task to unmount and remove directories
> > ".nilfs" and "file0", it trigger warning in nilfs_rmdir.
> >
> > Avoid to this issue, check i_size and i_nlink in nilfs_iget(), if they are
> > both 0, it means that this inode has been removed, and iput is executed to
> > reclaim it.
> >
> > [1]
> > WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407
> > Modules linked in:
> > CPU: 1 UID: 0 PID: 5824 Comm: syz-executor223 Not tainted 6.12.0-syzkaller-12113-gbcc8eda6d349 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> > RIP: 0010:drop_nlink+0xc4/0x110 fs/inode.c:407
> > Code: bb 70 07 00 00 be 08 00 00 00 e8 57 0b e6 ff f0 48 ff 83 70 07 00 00 5b 41 5c 41 5e 41 5f 5d c3 cc cc cc cc e8 9d 4c 7e ff 90 <0f> 0b 90 eb 83 44 89 e1 80 e1 07 80 c1 03 38 c1 0f 8c 5c ff ff ff
> > RSP: 0018:ffffc900037f7c70 EFLAGS: 00010293
> > RAX: ffffffff822124a3 RBX: 1ffff1100e7ae034 RCX: ffff88807cf53c00
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 0000000000000000 R08: ffffffff82212423 R09: 1ffff1100f8ba8ee
> > R10: dffffc0000000000 R11: ffffed100f8ba8ef R12: ffff888073d701a0
> > R13: 1ffff1100e79f5c4 R14: ffff888073d70158 R15: dffffc0000000000
> > FS: 0000555558d1e480(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000555558d37878 CR3: 000000007d920000 CR4: 00000000003526f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > <TASK>
> > nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342
> > vfs_rmdir+0x3a3/0x510 fs/namei.c:4394
> > do_rmdir+0x3b5/0x580 fs/namei.c:4453
> > __do_sys_rmdir fs/namei.c:4472 [inline]
> > __se_sys_rmdir fs/namei.c:4470 [inline]
> > __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470
> > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Reported-and-tested-by: syzbot+9260555647a5132edd48@...kaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=9260555647a5132edd48
> > Signed-off-by: Edward Adam Davis <eadavis@...com>
> > ---
> > fs/nilfs2/inode.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/nilfs2/inode.c b/fs/nilfs2/inode.c
> > index cf9ba481ae37..254a5e46f8ea 100644
> > --- a/fs/nilfs2/inode.c
> > +++ b/fs/nilfs2/inode.c
> > @@ -544,8 +544,15 @@ struct inode *nilfs_iget(struct super_block *sb, struct nilfs_root *root,
> > inode = nilfs_iget_locked(sb, root, ino);
> > if (unlikely(!inode))
> > return ERR_PTR(-ENOMEM);
> > - if (!(inode->i_state & I_NEW))
> > +
> > + if (!(inode->i_state & I_NEW)) {
> > + if (!inode->i_size && !inode->i_nlink) {
> > + make_bad_inode(inode);
> > + iput(inode);
> > + return ERR_PTR(-EIO);
> > + }
> > return inode;
> > + }
> >
> > err = __nilfs_read_inode(sb, root, ino, inode);
> > if (unlikely(err)) {
> > --
> > 2.47.0
>
> Thank you Edward.
>
> This fix seems good except for the i_size check, but I think we need
> to look into what's going on a bit more.
>
> I was unable to work for a while due to machine trouble, so I'd like
> to know if you have made any progress on your investigation.
>
> First, is this caused by a corrupted filesystem image? Or is it that
> the directories or files with the same inode number were generated
> during the namespace operations (due to a timing issue or something),
> and could this problem occur even if the original filesystem image is
> normal?
According to the log when I reproduced the problem, I analyzed that the
problem occurred like this:
CPU0 CPU1
==== ====
nilfs_mkdir // file0
nilfs_new_inode // ino is 11
mount // mount file0
umount // .nilfs, ino is 11
nilfs_rmdir // ino is 11, i_size = 0, i_nlink = 0
umount // file0, ino is 11
nilfs_rmdir // ino 11, i_size = 0, i_nlink = 0, trigger warning
>
> When I mounted the mount_0 image as read-only, the filesystem looked
> normal without such inode duplication.
>
> At least, nilfs_read_inode_common(), which reads inodes from block
> devices, is implemented to return an error with -ESTALE if i_nlink ==
> 0. So it seems that nilfs_iget() picked up this inode with i_nlilnk
> == 0 because it hit an inode being deleted in the inode cache. Why is
> that happening?
Are you talking about the following call trace?
If so, then because the value of inode->i_state is I_DIRTY (set in nilfs_mkdir)
it will not enter __nilfs_read_inode().
nilfs_iget()->
__nilfs_read_inode()->
nilfs_read_inode_common()
>
> Also, why do you put the i_size check as an AND condition?
i_size will set to 0 in nilfs_rmdir(), so check it too.
> i_size is independent of i_nlink and the inode lifecycles. If i_size
> is also broken, this check will not work properly.
> If something is not working and you have included it as a workaround,
> I would like to know about it.
BR,
Edward
Powered by blists - more mailing lists