On Mon, Jun 18, 2018 at 03:49:52AM +0000, Xu, Wen wrote: > Hi, > > Here is an issue I found when fuzzing V5 filesystem related with softlink. > > - Reproduce (4.17/for-next branch) > # mkdir mnt > # mount -t xfs final.img mnt > # gcc -o poc poc.c > # ./poc ./mnt This does not reproduce on my local dev tree. This is as much output as I get: > [ 315.207956] XFS (loop0): Mounting V5 Filesystem > [ 315.214851] XFS (loop0): Ending clean mount > [ 315.214976] Filesystem "loop0": reserve blocks depleted! Consider increasing reserve pool size. > [ 315.214979] XFS (loop0): Per-AG reservation for AG 0 failed. Filesystem may run out of space. > [ 315.214981] XFS (loop0): Per-AG reservation for AG 0 failed. Filesystem may run out of space. > [ 326.041728] XFS (loop0): Failed to remove inode(s) from unlinked list. Please free space, unmount and run xfs_repair. i.e. Nothing unexpected fails, I get ENOENT as expected once the baz -> ./baz symlink loop has been removed. Ok, now I'm betting that this has something to do with zero length symlinks not being caught correctly, given that a) we identified this flaw a few days ago, b) strlen(symlink_data_ptr) gets a null dereference indicating an empty symlink is being read, and c) there's a warning about failing to remove an inode from the unlinked list and that can leave symlinks with a zeroed in-memory data fork. Ok, so lets try a plain 4.17 + xfs/for-next. Yup, that does indeed fail. IOWs, the patch I wrote a few hours ago to prevent zero length symlinks from hitting the disk by not screwing with the inline inode data fork until the inode has been pulled from the unlinked list prevents the crash from occurring. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
