On Sat, Oct 31, 2015 at 2:39 PM, Ram Pai <linuxram@xxxxxxxxxx> wrote:
> On Sat, Oct 31, 2015 at 08:38:17AM -0400, Dan Streetman wrote:
>> On Fri, Oct 30, 2015 at 6:45 PM, Ram Pai <linuxram@xxxxxxxxxx> wrote:
>> > The nx-842 compressor overshoots the output buffer corrupting memory. Verified
>> > that the following patch fixes the issue on a little-endian system.
>> >
>> > Signed-off-by: Ram Pai <linuxram@xxxxxxxxxx>
>> > ---
>> > drivers/crypto/nx/nx-842-powernv.c | 2 +-
>> > 1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/drivers/crypto/nx/nx-842-powernv.c b/drivers/crypto/nx/nx-842-powernv.c
>> > index 3750e13..3b80ea7 100644
>> > --- a/drivers/crypto/nx/nx-842-powernv.c
>> > +++ b/drivers/crypto/nx/nx-842-powernv.c
>> > @@ -66,7 +66,7 @@ static void setup_indirect_dde(struct data_descriptor_entry *dde,
>> > unsigned int dde_count, unsigned int byte_count)
>> > {
>> > dde->flags = 0;
>> > - dde->count = dde_count;
>> > + dde->count = cpu_to_be32(dde_count);
>>
>> ->count is u8, I don't think this is correct...you could change
>> dde_count to a u8, but I'm skeptical that's required at all, are you
>> sure this is your problem? The dde->length should restrict the coproc
>> from r/w past the output buffer anyway, even if the ->count is too
>> large...
>
> Dan, you are right. The problem does resurface even after the above change.
> There is something else going on. Please ignore this patch for now.
>
> I see corruption, when the output buffer is smaller than needed to hold
> the compressed data. I expect it to return -ENOSPC, but its not; instead
> overshoots and corrupts.
what are the in/out buffer sizes and alignment when it overruns the
output buffer? and is it for compression or decompression? does it
happen if you disable CRC (since Haren just enabled it recently)?
>
> RP
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
