[PATCH] crypto: digest: Fix digesting over memory chunks > 4096 bytes

[Uwe Kleine-König]

There are two different cases that are handled in digest_file_window:

a) the file to digest is memmappable (e.g. /dev/mem)
b) it isn't (e.g. files in /)

In both cases a file is digested in hunks of (up to) 4096 bytes. After
each hunk in b) the buffer that is fed to digest_update() is then
overwritten using read() to get the next hunk to digest. In case a)
however it was forgotten to step forward in the buffer and instead the
same data was handed to digest_update() again and again.

So to fix that increase buffer by the number of bytes already digested
for case a) which is characterized by flags == 0.

Signed-off-by: Uwe Kleine-König <u.kleine-***@pengutronix.de>
---
Hello,

this is the obvious and minimal patch to fix this issue. Maybe it is
worth to simplify the function by splitting it in two where each one
handles one of the cases above.

Best regards
Uwe

crypto/digest.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/crypto/digest.c b/crypto/digest.c
index 7a8c3c092d7d..bc6de0b98f46 100644
--- a/crypto/digest.c
+++ b/crypto/digest.c
@@ -272,6 +272,9 @@ int digest_file_window(struct digest *d, const char *filename,
goto out_free;
size -= now;
len += now;
+
+ if (!flags)
+ buf += now;
}

if (sig)

[Lucas Stach]

Post by Uwe Kleine-König
a) the file to digest is memmappable (e.g. /dev/mem)
b) it isn't (e.g. files in /)
In both cases a file is digested in hunks of (up to) 4096 bytes. After
each hunk in b) the buffer that is fed to digest_update() is then
overwritten using read() to get the next hunk to digest. In case a)
however it was forgotten to step forward in the buffer and instead the
same data was handed to digest_update() again and again.
So to fix that increase buffer by the number of bytes already digested
for case a) which is characterized by flags == 0.
---
Hello,
this is the obvious and minimal patch to fix this issue. Maybe it is
worth to simplify the function by splitting it in two where each one
handles one of the cases above.

Yes, making this less confusing to the casual reader of the code seems
like a good idea. I've applied this minimal fix for master.

Regards,
Lucas