On 2018/06/15 4:00, Tigran Aivazian wrote: >> However, that doesn't address the issue of the _upper_ limit of >> s_start, i.e. it can still get (on an invalid image pretending to be >> BFS) arbitrarily large and cause the allocation to fail as you >> described. I will dig a bit more (in my memories :) and try to come up >> with the check which doesn't reject a valid BFS image and at the same >> time restricts s_start (or imap_len which ultimately depends on it) >> sufficiently to prevent wild kernel memory allocation requests. >> >> Btw, I included in the WikiPedia article "Boot File System" a >> reference to the original "BFS kernel support" webpage from those >> ancient days: http://ftp.linux.org.uk/pub/linux/iBCS/bfs/ > > Ah, it turned out easier than I thought! The maximum number of inodes > of a BFS filesystem is 512, so an inode map cannot be longer than 65 > bytes. Well, we can be generous and restrict imap_len to 128 and be > done with it :) > > Namely, if the calculated imap_len turns out to be greater than 128, > then something is definitely wrong and the filesystem image should be > rejected as corrupted. > So, the constraint is if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) || le32_to_cpu(bfs_sb->s_end) > What_is_the_number_here) you can write the fix yourself...
