{"push_id":660427080,"size":1,"distinct_size":1,"ref":"refs/heads/lollipop_staging","head":"e964e71e1fa9810ec270fdd799bdae9e9e0a003a","before":"93b5289120eb2259bf2336cf583fb015ddb801a9","commits":[{"sha":"e964e71e1fa9810ec270fdd799bdae9e9e0a003a","author":{"email":"45077a34947a1ae82e6576c6adeb38fe04811905@gmail.com","name":"Eryu Guan"},"message":"ext4: check for overlapping extents in ext4_valid_extent_entries()\n\ncommit 5946d089379a35dda0e531710b48fca05446a196 upstream.\n\nA corrupted ext4 may have out of order leaf extents, i.e.\n\nextent: lblk 0--1023, len 1024, pblk 9217, flags: LEAF UNINIT\nextent: lblk 1000--2047, len 1024, pblk 10241, flags: LEAF UNINIT\n             ^^^^ overlap with previous extent\n\nReading such extent could hit BUG_ON() in ext4_es_cache_extent().\n\n\tBUG_ON(end < lblk);\n\nThe problem is that __read_extent_tree_block() tries to cache holes as\nwell but assumes 'lblk' is greater than 'prev' and passes underflowed\nlength to ext4_es_cache_extent(). Fix it by checking for overlapping\nextents in ext4_valid_extent_entries().\n\nI hit this when fuzz testing ext4, and am able to reproduce it by\nmodifying the on-disk extent by hand.\n\nAlso add the check for (ee_block + len - 1) in ext4_valid_extent() to\nmake sure the value is not overflow.\n\nRan xfstests on patched ext4 and no regression.\n\nCc: Lukáš Czerner <lczerner@redhat.com>\nSigned-off-by: Eryu Guan <guaneryu@gmail.com>\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Starship-Android/android_kernel_lge_hammerhead-starship/commits/e964e71e1fa9810ec270fdd799bdae9e9e0a003a"}]}