[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250109063939.1937072-1-lizhi.xu@windriver.com>
Date: Thu, 9 Jan 2025 14:39:39 +0800
From: Lizhi Xu <lizhi.xu@...driver.com>
To: <viro@...iv.linux.org.uk>
CC: <aivazian.tigran@...il.com>, <linux-kernel@...r.kernel.org>,
<lizhi.xu@...driver.com>,
<syzbot+80e60df48923e1b7691d@...kaller.appspotmail.com>,
<syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH] bfs: put a inode if link count is 0
On Thu, 9 Jan 2025 06:22:16 +0000, Al Viro wrote:
> > The reproducer performs the rename operation on the file twice in succession
> > and changes the file to the same file name. After the first rename operation,
> > the number of links in the inode is set to 0. In the second execution, the
> > same inode is used, resulting in a 0 value warning for i_nlink.
> >
> > To avoid this issue, put the target inode before exiting the bfs_rename.
>
> This is completely insane - you get an extra drop of in-core inode
> refcount, which *will* end up with dangling pointer and memory corruption.
> Besides, there is a perfectly legitimate case when you open a file and
> rename something on top of it. It MUST remain open and alive until the
> last in-core reference to inode goes away, which must not happen before
> close().
In the reproducer, changes the file to the same file, the same file name is
"file0", file0 uses mknod to create its inode and sets the i_nlink value to 1.
There is no operation to open file0 in the reproducer. Is this situation also
as you said?
Powered by blists - more mailing lists