xfs: fix remote symlinks on V5/CRC filesystems

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 <[email protected]>

Cc [email protected]

---

fs/xfs/xfs_symlink.c +0 -0

index 3df411e..40c0765 100644

Quoted 29 lines · Eric Sandeen

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 <[email protected]>

Cc [email protected]

---

fs/xfs/xfs_symlink.c +0 -0

index 3df411e..40c0765 100644

fs/xfs/xfs_symlink.c xfs_readlink_bmap( · line 110

Quoted 8 lines

fs/xfs/xfs_symlink.c +1 -1

@@ -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 <[email protected]>

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?

Quoted 41 lines · Dave Chinner

Quoted 29 lines · Eric Sandeen

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 <[email protected]>

Cc [email protected]

---

fs/xfs/xfs_symlink.c +0 -0

index 3df411e..40c0765 100644

fs/xfs/xfs_symlink.c xfs_readlink_bmap( · line 110

Quoted 8 lines

fs/xfs/xfs_symlink.c +1 -1

@@ -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:

Quoted 6 lines

Reviewed-by Dave Chinner <[email protected]>

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?

It was a smaller part of a larger test harness I was using with xfs_metadump, which was trying to create every type of on-disk metadata. However, even with that I only stumbled on it, because I was only verifying that the results were uncorrupted and consistent with the original, not actually verifying that what I created was still there (on the original!)

So, I don't have a test specific to this, no, but could certainly write one; I suppose a quick targeted fstest for just this bug would be ok, although a test w/ broader scope might make sense too.

Quoted 55 lines · Eric Sandeen

Quoted 41 lines · Dave Chinner

Quoted 29 lines · Eric Sandeen

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 <[email protected]>

Cc [email protected]

---

fs/xfs/xfs_symlink.c +0 -0

index 3df411e..40c0765 100644

fs/xfs/xfs_symlink.c xfs_readlink_bmap( · line 110

Quoted 8 lines

fs/xfs/xfs_symlink.c +1 -1

@@ -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:

Quoted 6 lines

Reviewed-by Dave Chinner <[email protected]>

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?

It was a smaller part of a larger test harness I was using with xfs_metadump, which was trying to create every type of on-disk metadata. However, even with that I only stumbled on it, because I was only verifying that the results were uncorrupted and consistent with the original, not actually verifying that what I created was still there (on the original!)

Quoted 3 lines

So, I don't have a test specific to this, no, but could certainly write one; I suppose a quick targeted fstest for just this bug would be ok, although a test w/ broader scope might make sense too.

Sure, the metadump test is a good idea, but my question is more asking why our broader tests haven't already covered verifying MAXPATHLEN symlinks work correctly or not. Surely symlink correctness is verified *somewhere* (even outside xfstests, e.g. LTP?), and if so why haven't we seen this before now? If not, then I'd suggest we've just uncovered a potential Nest O' Bugs...

Cheers,

Dave.

Quoted 60 lines · Dave Chinner

Quoted 58 lines · Eric Sandeen

Quoted 41 lines · Dave Chinner

Quoted 29 lines · Eric Sandeen

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 <[email protected]>

Cc [email protected]

---

fs/xfs/xfs_symlink.c +0 -0

index 3df411e..40c0765 100644

fs/xfs/xfs_symlink.c xfs_readlink_bmap( · line 110

Quoted 8 lines

fs/xfs/xfs_symlink.c +1 -1

@@ -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:

Quoted 6 lines

Reviewed-by Dave Chinner <[email protected]>

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?

It was a smaller part of a larger test harness I was using with xfs_metadump, which was trying to create every type of on-disk metadata. However, even with that I only stumbled on it, because I was only verifying that the results were uncorrupted and consistent with the original, not actually verifying that what I created was still there (on the original!)

So, I don't have a test specific to this, no, but could certainly write one; I suppose a quick targeted fstest for just this bug would be ok, although a test w/ broader scope might make sense too.

Quoted 6 lines

Sure, the metadump test is a good idea, but my question is more asking why our broader tests haven't already covered verifying MAXPATHLEN symlinks work correctly or not. Surely symlink correctness is verified *somewhere* (even outside xfstests, e.g. LTP?), and if so why haven't we seen this before now? If not, then I'd suggest we've just uncovered a potential Nest O' Bugs...

A) CRCs aren't default

B) I bet LTP doesn't do a remount to verify on-disk persistence

Quoted 61 lines · Eric Sandeen

Quoted 60 lines · Dave Chinner

Quoted 58 lines · Eric Sandeen

Quoted 41 lines · Dave Chinner

Quoted 29 lines · Eric Sandeen

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 <[email protected]>

Cc [email protected]

---

fs/xfs/xfs_symlink.c +0 -0

index 3df411e..40c0765 100644

fs/xfs/xfs_symlink.c xfs_readlink_bmap( · line 110

Quoted 8 lines

fs/xfs/xfs_symlink.c +1 -1

@@ -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:

Quoted 6 lines

Reviewed-by Dave Chinner <[email protected]>

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?

It was a smaller part of a larger test harness I was using with xfs_metadump, which was trying to create every type of on-disk metadata. However, even with that I only stumbled on it, because I was only verifying that the results were uncorrupted and consistent with the original, not actually verifying that what I created was still there (on the original!)

So, I don't have a test specific to this, no, but could certainly write one; I suppose a quick targeted fstest for just this bug would be ok, although a test w/ broader scope might make sense too.

Quoted 8 lines

Quoted 6 lines

Sure, the metadump test is a good idea, but my question is more asking why our broader tests haven't already covered verifying MAXPATHLEN symlinks work correctly or not. Surely symlink correctness is verified *somewhere* (even outside xfstests, e.g. LTP?), and if so why haven't we seen this before now? If not, then I'd suggest we've just uncovered a potential Nest O' Bugs...

A) CRCs aren't default

Yet many people have been testing them and putting them in production (e.g. SLES 12), so they *should* have been tested.

Quoted 1 line

B) I bet LTP doesn't do a remount to verify on-disk persistence

Just reading back the symlink should expose the bug, right? Or is it being hidden by the dentry cache or something else?

Cheers,

Dave.