On 2018/06/14 22:05, Tigran Aivazian wrote: > On 14 June 2018 at 13:38, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: >> Consider, currently we can have a bfs image that works fine on one >> kernel, but fails to mount on another just because it happens so that >> one could allocate 4MB with kmalloc, but another can't (different >> allocator/different settings/different kernel revision). > > Yes, but this would only happen _without_ the validation proposed by > Tetsuo Handa. If we check s_start then the invalid enormous allocation > request will not be made and what you describe won't not happen. > What is possible largest value for imap_len ? info->si_lasti = (le32_to_cpu(bfs_sb->s_start) - BFS_BSIZE) / sizeof(struct bfs_inode) + BFS_ROOT_INO - 1; imap_len = (info->si_lasti / 8) + 1; info->si_imap = kzalloc(imap_len, GFP_KERNEL); Since sizeof(struct bfs_inode) is 64 and bfs_sb->s_start is unsigned 32bits integer (where constraints is BFS_BSIZE <= bfs_sb->s_start <= bfs_sb->s_end), theoretically it is possible to assign bfs_sb->s_start > 2GB (apart from whether such value makes sense). Then, isn't it possible that imap_len > 4M and still hit KMALLOC_MAX_SIZE limit?
