On Sat, Nov 16, 2024 at 09:02:07AM +0800, Lizhi Xu wrote: > Our idea is the same. Because d_is_symlink() has confirmed the mode of > symlink in step_into(), I will confirm whether the mode of symlink's inode > has changed when the value of i_link is 2 in pick_link(). > > do something and return > > > > so we are checking whether the inode is a symlink before calling > > pick_link(). And yes, the d_is_symlink() is using cached type in > > dentry->d_flags so they could mismatch. But inode is not supposed to change > > its type during its lifetime so if there is a mismatch that is the problem > > that needs to be fixed. > I think syzbot executed the following two syscalls when triggering this problem: > > link(&(0x7f0000000200)='./file0\x00', &(0x7f0000000240)='./bus\x00') > mount$overlay(0x0, &(0x7f00000000c0)='./bus\x00', 0x0, 0x0, 0x0) > > Obviously, this is to mount a link. Whether the mount operation itself will > change or corrupt the i_link value and mode value of the symlink is not > clear to me yet. Odds are, it's not a valid struct inode instance in the first place. It's not inode->i_link that is a problem (*nothing* should ever store that value in there and ntfs doesn't even try that - grep and you'll see); it's inode itself. Have you tried KASAN-enabled build? Might be interesting to see if it catches anything...
