While very unlikely, it is possible for arch_get_random_long() to fail in the middle of the loop in xfer_secondary_pool(), which would mean that the loop could stop with only part of u.hwrand populated, leading to mix_pool_bytes() injecting uninitialized or already injected bytes instead of fresh bytes. This changes the mix_pool_bytes() call to only inject the successfully gathered bytes.
Signed-off-by: Kees Cook <[email protected]> Cc: [email protected] --- Should be applied on top of the tytso/random dev branch. --- drivers/char/random.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index aaf4629..6fc3128 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -879,7 +879,7 @@ static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes) if (arch_get_random_long(&u.hwrand[i])) break; if (i) - mix_pool_bytes(r, &u.hwrand, sizeof(u.hwrand), 0); + mix_pool_bytes(r, &u.hwrand, i * sizeof(u.hwrand[0]), 0); } /* -- 1.7.0.4 -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
