]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
xfs: don't expose internal symlink metadata buffers to the vfs
authorDarrick J. Wong <djwong@kernel.org>
Wed, 15 Dec 2021 20:07:41 +0000 (12:07 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 25 Oct 2023 09:58:54 +0000 (11:58 +0200)
commite7a2aa7770d371bc03fcfb0ac3c5145b68d6cb5f
tree1d59d3d65410afde520480ffda004b76428f5625
parentfe5c6fbc5e4a956c2a854efbaef6b408c4c11c2a
xfs: don't expose internal symlink metadata buffers to the vfs

commit 7b7820b83f230036fc48c3e7fb280c48c58adebf upstream.

Ian Kent reported that for inline symlinks, it's possible for
vfs_readlink to hang on to the target buffer returned by
_vn_get_link_inline long after it's been freed by xfs inode reclaim.
This is a layering violation -- we should never expose XFS internals to
the VFS.

When the symlink has a remote target, we allocate a separate buffer,
copy the internal information, and let the VFS manage the new buffer's
lifetime.  Let's adapt the inline code paths to do this too.  It's
less efficient, but fixes the layering violation and avoids the need to
adapt the if_data lifetime to rcu rules.  Clearly I don't care about
readlink benchmarks.

As a side note, this fixes the minor locking violation where we can
access the inode data fork without taking any locks; proper locking (and
eliminating the possibility of having to switch inode_operations on a
live inode) is essential to online repair coordinating repairs
correctly.

Reported-by: Ian Kent <raven@themaw.net>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Chandan Babu R <chandanbabu@kernel.org>
Acked-by: Leah Rumancik <leah.rumancik@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/xfs/xfs_iops.c
fs/xfs/xfs_symlink.c