On Sat, Feb 20, 2021 at 8:33 AM Ben Widawsky <ben.widaw...@intel.com> wrote:
>
> On 21-02-19 20:22:00, Konrad Rzeszutek Wilk wrote:
> > ..snip..
> > > +static int handle_mailbox_cmd_from_user(struct cxl_mem *cxlm,
> > > + const struct cxl_mem_command *cmd,
> > > + u64 in_payload, u64 out_payload,
> > > + s32 *size_out, u32 *retval)
> > > +{
> > > + struct device *dev = &cxlm->pdev->dev;
> > > + struct mbox_cmd mbox_cmd = {
> > > + .opcode = cmd->opcode,
> > > + .size_in = cmd->info.size_in,
> > > + .size_out = cmd->info.size_out,
> > > + };
> > > + int rc;
> > > +
> > > + if (cmd->info.size_out) {
> > > + mbox_cmd.payload_out = kvzalloc(cmd->info.size_out,
> > > GFP_KERNEL);
> > > + if (!mbox_cmd.payload_out)
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + if (cmd->info.size_in) {
> > > + mbox_cmd.payload_in =
> > > vmemdup_user(u64_to_user_ptr(in_payload),
> > > + cmd->info.size_in);
> > > + if (IS_ERR(mbox_cmd.payload_in))
> > > + return PTR_ERR(mbox_cmd.payload_in);
> >
> > Not that this should happen, but what if info.size_out was set? Should
> > you also free mbox_cmd.payload_out?
> >
>
> Thanks Konrad.
>
> Dan, do you want me to send a fixup patch? This bug was introduced from
> v4->v5.
Yes, please, incremental to libnvdimm-for-next which I'm planning to
send to Linus on Tuesday.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
