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@denx.de Cc: Ian Ray ian.ray@ge.com Cc: Martyn Welch martyn.welch@collabora.co.uk Cc: Stefano Babic sbabic@denx.de Cc: Tom Rini trini@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.