lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ