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 <keesc...@chromium.org>
Cc: sta...@vger.kernel.org
---
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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
