On Sun, Aug 18, 2019 at 10:16:50AM +0200, Richard Weinberger wrote: > ----- Urspr?ngliche Mail ----- > >> While digging a little into the code I noticed that you have very few > >> checks of the on-disk data. > >> For example ->u.i_blkaddr. I gave it a try and created a > >> malformed filesystem where u.i_blkaddr is 0xdeadbeef, it causes the kernel > >> to loop forever around erofs_read_raw_page(). > > > > I don't fuzz all the on-disk fields for EROFS, I will do later.. > > You can see many in-kernel filesystems are still hardening the related > > stuff. Anyway, I will dig into this field you mentioned recently, but > > I think it can be fixed easily later. > > This is no excuse to redo all these bugs. :-) I agree with you, but what can we do now is trying our best to fuzz all the fields. So, what is your opinion about EROFS? > > I know that many in-kernel filesystems trust the disk ultimately, this is a > problem and huge attack vector. I EROFS already has many error handing paths to recover corrupted images, and your discovery is a bug out of one error handing path miswritten by me. I cannot make a guarantee that all the new things (every new kernel version will introduce new feature / new code) are bug-free since I am not a machine or code parser. My answer about this EROFS will be more stable with our development, we have a dedicated team with paid job, and since we currently use EROFS on the top of dm-verity for current Android, which will keep us from corrupted images. But yes, we will focus on fuzzing all the images for generic usages, and we will backport all these patches to old stable versions. Thanks, Gao Xiang > > Thanks, > //richard _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
