On Wed, May 14, 2025 at 06:39:40AM +0800, Edward Adam Davis wrote: > In the reproducer, when calling renameat2(), olddirfd and newdirfd passed > are the same value r0, see [1]. This situation should be avoided. > > [1] > renameat2(r0, &(0x7f0000000240)='./bus/file0\x00', r0, &(0x7f00000001c0)='./file0\x00', 0x0) > > Reported-by: syzbot+321477fad98ea6dd35b7@xxxxxxxxxxxxxxxxxxxxxxxxx > Closes: https://syzkaller.appspot.com/bug?extid=321477fad98ea6dd35b7 > Tested-by: syzbot+321477fad98ea6dd35b7@xxxxxxxxxxxxxxxxxxxxxxxxx > Signed-off-by: Edward Adam Davis <eadavis@xxxxxx> > --- > fs/namei.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/namei.c b/fs/namei.c > index 84a0e0b0111c..ff843007ca94 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -5013,7 +5013,7 @@ int vfs_rename(struct renamedata *rd) > struct name_snapshot old_name; > bool lock_old_subdir, lock_new_subdir; > > - if (source == target) > + if (source == target || old_dir == target) > return 0; What the hell? 1) olddirfd and newdirfd have nothing to do with vfs_rename() - they are bloody well gone by the time we get there. 2) there's nothing wrong with having the same value passed in both - and it's certainly not a "quietly do nothing". 3) the check added in this patch is... odd. You are checking essentically for rename("foo/bar", "foo"). It should fail (-ENOTEMPTY or -EINVAL, depending upon RENAME_EXCHANGE in flags) without having reached vfs_rename().
