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(-)

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);
-- 
2.34.1

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.