Hi Dave, I feel I can get your point a bit. Anyway recently I am fuzzing log section of XFS. I reported four new bugs to mail list today. They are all memory corruption issues, and I think some of them are enough to be used to perform controlled write and code execution. And I feel these bugs are not complex ones but exist there that cannot simply be covered by CRC protection? In my humble opinions, CRC protection mainly hardens the integrity of the metadata instead of eliminating malicious metadata leading to unexpected behaviors. I am not very sure considering my limited knowledge on XFS but you can take a look on them and see the severity of these issues. Thanks, Wen > On Jun 12, 2018, at 6:40 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Mon, Jun 11, 2018 at 07:36:48PM +0000, Xu, Wen wrote: >> When mounting a crafted xfs v4 image, the kernel hangs and never returns for mount operation. Suspect potential deadlock in log recovery exists. Not sure it is considered as a bug or not. >> >> - Reproduce (on 4.17 upstream kernel) >> # mkdir mnt >> # mount -t xfs 0.img mnt >> >> The image file (0.img.zip) is available here: https://bugzilla.kernel.org/attachment.cgi?id=276475 > > So it's a filesystem with a log that has bit corruptions in it's log > record headers, and log CRCs are turned off. All kernels since late > 2012 have CRC'd log records for both v4 and v5 filesystems. Hence > any remotely recent kernel faced wih bit errors in the journal are > going to behave differently - corruption warnings will be issued > first, and while v4 filesystems will continue to try to mount, a v5 > filesystem will refuse to mount. And kernels old enough not to CRC > log records are unlikely to ever get bug fixes for maliciously > corrupted log records. > > As such, I'm going to consider this a low priority right now. > Protecting log recovery against anything more than random bit errors > is a fairly major undertaking, and not something I plan on doing > in the near term... > > 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
