On Fri, Oct 31, 2014 at 07:50:11AM +0100, Greg Kurz wrote:
> The add_early_randomness() function in drivers/char/hw_random/core.c passes
> a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall()
> returns four 64-bit values and trashes 16 bytes on the stack.
>
> This bug has been
On Fri, Oct 31, 2014 at 10:31:41AM +0100, Greg Kurz wrote:
>
> > > Cc'ing stable as I could reproduce back to 3.15.10
> >
> > The right way to CC stable for a patch that isn't yet in upstream is to add:
> >
> > CC: sta...@vger.kernel.org
> >
> > Before your Signed-off-by. They will then pick it
On Fri, 31 Oct 2014 18:00:12 +1100
Michael Ellerman wrote:
> On Fri, 2014-10-31 at 07:50 +0100, Greg Kurz wrote:
> > The add_early_randomness() function in drivers/char/hw_random/core.c passes
> > a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall()
> > returns four 64-bit va
On Fri, 2014-10-31 at 07:50 +0100, Greg Kurz wrote:
> The add_early_randomness() function in drivers/char/hw_random/core.c passes
> a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall()
> returns four 64-bit values and trashes 16 bytes on the stack.
Hmm, thanks. I thought I'd f
The add_early_randomness() function in drivers/char/hw_random/core.c passes
a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall()
returns four 64-bit values and trashes 16 bytes on the stack.
This bug has been lying around for a long time. It got unveiled by:
commit d3cc799647
