[U-Boot] [PATCH] fs: ext4: Prevent erasing buffer past file size

[Marek Vasut]

On 07/23/2018 04:09 PM, Tom Rini wrote:
> On Mon, Jul 23, 2018 at 11:42:12AM +0200, Marek Vasut wrote:
> 
>> The variable 'n' represents the number of bytes to be read from a certain
>> offset in a file, to a certain offset in buffer 'buf'. The variable 'len'
>> represents the length of the entire file, clamped correctly to avoid any
>> overflows.
>>
>> Therefore, comparing 'n' and 'len' to determine whether clearing 'n'
>> bytes of the buffer 'buf' at a certain offset would clear data past
>> buffer 'buf' cannot lead to a correct result, since the 'n' does not
>> contain the offset from the beginning of the file.
>>
>> This patch keeps track of the amount of data read and checks for the
>> buffer overflow by comparing the 'n' to the remaining amount of data
>> to be read instead.
>>
>> Signed-off-by: Marek Vasut <marex at denx.de>
>> Cc: Ian Ray <ian.ray at ge.com>
>> Cc: Martyn Welch <martyn.welch at collabora.co.uk>
>> Cc: Stefano Babic <sbabic at denx.de>
>> Cc: Tom Rini <trini at konsulko.com>
>> Fixes: ecdfb4195b20 ("ext4: recover from filesystem corruption when reading")
> 
> Good catch.  Can this problem also be recreated/tested with
> test/fs/fs-test.sh?  Thanks!
> 
I think so. I'd memalign() a buffer with some safe space around it, ie.
a 4k page on each side and poison it with a pattern. I'd then read a
file which is not ext4 FS block size aligned into 1-page offset from the
beginning of that buffer . Finally, I'd check if exactly the size of the
file was changed in that buffer and the poisoned area of the buffer
still contains the poison or not.

|................poison................|
                    |
                    v
|...poison...|file...|.DZ.|...poison...|

If DZ is poison, everything is OK.
If DZ is 0x0, the ext4 corruption happened.

-- 
Best regards,
Marek Vasut