| Message ID | 20240907172111.127817-1-ghanshyam1898@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | VFS: check i_nlink count before trying to unlink | expand |
On Sat, Sep 07, 2024 at 10:51:10PM +0530, Ghanshyam Agrawal wrote: > Reported-by: syzbot+41b43444de86db4c5ed1@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=41b43444de86db4c5ed1 > Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com> As far as I can tell, you have jfs_unlink() find and remove a directory entry without any problems, then find that the damn thing had corrupted inode link count (presumably due to creatively fucked up image). IF that's the case, NAK. vfs_unlink() is *NOT* the place to try and cope with that kind of crap. What's more, having unlink(2) quietly succeed and do nothing to directory is simply wrong.
diff --git a/fs/namei.c b/fs/namei.c index 5512cb10fa89..9e5214dfd05d 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -4419,7 +4419,8 @@ int vfs_unlink(struct mnt_idmap *idmap, struct inode *dir, error = try_break_deleg(target, delegated_inode); if (error) goto out; - error = dir->i_op->unlink(dir, dentry); + if (dentry->d_inode->i_nlink) + error = dir->i_op->unlink(dir, dentry); if (!error) { dont_mount(dentry); detach_mounts(dentry);
Reported-by: syzbot+41b43444de86db4c5ed1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=41b43444de86db4c5ed1 Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com> --- fs/namei.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)