[PATCH] xfs: fix remote symlinks on V5/CRC filesystems

[Dave Chinner]

On Mon, Jun 15, 2015 at 05:13:50PM -0500, Eric Sandeen wrote:
> If we create a CRC filesystem, mount it, and create a symlink with
> a path long enough that it can't live in the inode, we get a very
> strange result upon remount:
> 
> # ls -l mnt
> total 4
> lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM
> 
> XSLM is the V5 symlink block header magic (which happens to be
> followed by a NUL, so the string looks terminated).
> 
> xfs_readlink_bmap() advanced cur_chunk by the size of the header
> for CRC filesystems, but never actually used that pointer; it
> kept reading from bp->b_addr, which is the start of the block,
> rather than the start of the symlink data after the header.
> 
> Looks like this problem goes back to v3.10.
> 
> Fixing this gets us reading the proper link target, again.
> 
> Signed-off-by: Eric Sandeen <sandeen at redhat.com>
> Cc: stable at vger.kernel.org
> ---
> 
> diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c
> index 3df411e..40c0765 100644
> --- a/fs/xfs/xfs_symlink.c
> +++ b/fs/xfs/xfs_symlink.c
> @@ -104,7 +104,7 @@ xfs_readlink_bmap(
>  			cur_chunk += sizeof(struct xfs_dsymlink_hdr);
>  		}
>  
> -		memcpy(link + offset, bp->b_addr, byte_cnt);
> +		memcpy(link + offset, cur_chunk, byte_cnt);
>  
>  		pathlen -= byte_cnt;
>  		offset += byte_cnt;

Looks like the correct fix, so:

Reviewed-by: Dave Chinner <dchinner at redhat.com>

However, it raises a more disturbing question: how did we not trip
over this until now? I though we had long symlink test coverage in
xfstests but clearly we haven't - do you have a test that closes
this verification hole?

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com