Hi Al, On 2018/11/3 3:42, Al Viro wrote: > On Fri, Nov 02, 2018 at 04:07:01AM +0000, Al Viro wrote: >> On Thu, Nov 01, 2018 at 11:59:23PM +0000, David Howells wrote: >> >>> (*) mount-api-core. These are the internal-only patches that add the >>> fs_context, the legacy wrapper and the security hooks and make certain >>> filesystems make use of it. >> >> FWIW, while rereading that series I'd spotted something very odd in erofs. >> It's orthogonal to everything else, but just to make sure it doesn't get >> lost: >> * sbi->dev_name thing in erofs is used only for debugging printks, >> basically. Just use sb->s_id[] and be done with that. >> * dump struct erofs_mount_private - you don't need dev_name in >> your erofs_fill_super(). Just use mount_bdev() in usual fashion. >> * what the hell are you doing with ->s_root??? Why would you >> possibly want it hashed and what kind of dcache lookup could find it? >> That d_rehash() looks deeply confused; what are you trying to do there? > > ... and while we are at it, what happens to > unsigned int nameoff = le16_to_cpu(de[mid].nameoff); > unsigned int matched = min(startprfx, endprfx); > > struct qstr dname = QSTR_INIT(data + nameoff, > unlikely(mid >= ndirents - 1) ? > maxsize - nameoff : > le16_to_cpu(de[mid + 1].nameoff) - nameoff); > > /* string comparison without already matched prefix */ > int ret = dirnamecmp(name, &dname, &matched); > if le16_to_cpu(de[...].nameoff) is not monotonically increasing? I.e. > what's to prevent e.g. (unsigned)-1 ending up in dname.len? > > Corrupted fs image shouldn't oops the kernel...
Yes, thanks for pointing out. :) I will add more boundary check later before moving into fs/ directory... erofs now is under dm-verity for our HUAWEI mobile phone, so it doesn't be corruptted. I will add more checks and meta checksum later after EROFS productization successfully... :) Thanks, Gao Xiang >
