On Tue, 2016-04-12 at 12:01 -0500, Tom Lendacky wrote: > On 04/12/2016 09:28 AM, Greg Kroah-Hartman wrote: > > > > On Tue, Apr 12, 2016 at 02:56:52AM +0100, Ben Hutchings wrote: > > > > > > On Sun, 2016-04-10 at 11:34 -0700, Greg Kroah-Hartman wrote: [...] > > > > - state->type = rctx->type; > > > > - state->msg_bits = rctx->msg_bits; > > > > - state->first = rctx->first; > > > > - memcpy(state->ctx, rctx->ctx, sizeof(state->ctx)); > > > > - state->buf_count = rctx->buf_count; > > > > - memcpy(state->buf, rctx->buf, sizeof(state->buf)); > > > > + state.type = rctx->type; > > > > + state.msg_bits = rctx->msg_bits; > > > > + state.first = rctx->first; > > > > + memcpy(state.ctx, rctx->ctx, sizeof(state.ctx)); > > > > + state.buf_count = rctx->buf_count; > > > > + memcpy(state.buf, rctx->buf, sizeof(state.buf)); > > > > + > > > > + /* 'out' may not be aligned so memcpy from local variable */ > > > > + memcpy(out, &state, sizeof(state)); > > > [...] > > > > > > The padding was not initialised, but here we copy it to userland. > > Nice catch. Given that the user/kernel structure here doesn't seem very > > sane (implicit padding, etc.), shouldn't that be where this is fixed up > > to be a properly packed structure? Or have padding where needed, along > > with a memset() call? > The structure is not meant for use outside the kernel - it's an opaque > blob that will be processed by the driver import function. So would it > be enough to just memset the struct ccp_sha_exp_ctx state variable to 0 > before setting and copying it? That should take care of any padding not > being initialized. I think that would be enough. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't.
Attachment:
signature.asc
Description: This is a digitally signed message part