Re: [PATCH 5.10 2/2] fuse: fix illegal access to inode with reused nodeid

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sun, Sep 05, 2021 at 10:08:33AM +0300, Amir Goldstein wrote:
> [ Upstream commit 15db16837a35d8007cb8563358787412213db25e ]
> 
> Server responds to LOOKUP and other ops (READDIRPLUS/CREATE/MKNOD/...)
> with ourarg containing nodeid and generation.
> 
> If a fuse inode is found in inode cache with the same nodeid but different
> generation, the existing fuse inode should be unhashed and marked "bad" and
> a new inode with the new generation should be hashed instead.
> 
> This can happen, for example, with passhrough fuse filesystem that returns
> the real filesystem ino/generation on lookup and where real inode numbers
> can get recycled due to real files being unlinked not via the fuse
> passthrough filesystem.
> 
> With current code, this situation will not be detected and an old fuse
> dentry that used to point to an older generation real inode, can be used to
> access a completely new inode, which should be accessed only via the new
> dentry.
> 
> Note that because the FORGET message carries the nodeid w/o generation, the
> server should wait to get FORGET counts for the nlookup counts of the old
> and reused inodes combined, before it can free the resources associated to
> that nodeid.
> 
> Stable backport notes:
> * This is not a regression. The bug has been in fuse forever, but only
>   a certain class of low level fuse filesystems can trigger this bug
> * Because there is no way to check if this fix is applied in runtime,
>   libfuse test_examples.py tests this fix with hardcoded check for
>   kernel version >= 5.14
> * After backport to stable kernel(s), the libfuse test can be updated
>   to also check minimal stable kernel version(s)
> * Depends on "fuse: fix bad inode" which is already applied to stable
>   kernels v5.4.y and v5.10.y
> * Required backporting helper inode_wrong_type()

All now queued up, thanks!

greg k-h