From: Dan Carpenter <dan.carpenter@oracle.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Laurent Navet <laurent.navet@gmail.com>,
devel@driverdev.osuosl.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"line6linux-devel@lists.sourceforge.net"
<line6linux-devel@lists.sourceforge.net>,
kernel-janitors@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Line6linux-devel] [PATCH] line6: Use kmemdup rather than duplicating its implementation
Date: Wed, 5 Dec 2012 01:25:29 +0300 [thread overview]
Message-ID: <20121204222529.GK6568@mwanda> (raw)
In-Reply-To: <CAJSP0QXcv3CYE=4Ci=vRZQgHU=nDjAYx3kbbCnVgGfcn0seTDg@mail.gmail.com>
On Mon, Dec 03, 2012 at 05:34:07PM +0100, Stefan Hajnoczi wrote:
> On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet <laurent.navet@gmail.com> wrote:
> > staging: line6: driver.c
> > The semantic patch that makes this output is available
> > in scripts/coccinelle/api/memdup.cocci.
> >
> > Signed-off-by: Laurent Navet <laurent.navet@gmail.com>
> > ---
> > drivers/staging/line6/driver.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
> > index f5c19b2..e1d6241 100644
> > --- a/drivers/staging/line6/driver.c
> > +++ b/drivers/staging/line6/driver.c
> > @@ -331,14 +331,13 @@ int line6_version_request_async(struct usb_line6 *line6)
> > char *buffer;
> > int retval;
> >
> > - buffer = kmalloc(sizeof(line6_request_version), GFP_ATOMIC);
> > + buffer = kmemdup(line6_request_version,
> > + sizeof(line6_request_version), GFP_ATOMIC);
> > if (buffer == NULL) {
> > dev_err(line6->ifcdev, "Out of memory");
> > return -ENOMEM;
> > }
> >
> > - memcpy(buffer, line6_request_version, sizeof(line6_request_version));
> > -
> > retval = line6_send_raw_message_async(line6, buffer,
> > sizeof(line6_request_version));
> > kfree(buffer);
> > --
> > 1.7.10.4
>
> Your change is fine but I'm not sure whether we should allocate memory
> in the first place:
>
> line6_send_raw_message_async() returns before the transfer is
> complete. It submits one or more URBs but I cannot see a guarantee
> that the buffer is no longer needed. It seems unsafe to kfree(buffer)
> before the request is complete.
>
As Greg pointed out we do need to allocate the memory to make DMA
work. But you're right that it is a use after free bug. We should
move the kfree(msg->buffer) to inside line6_async_request_sent().
I can send a fix for this tomorrow or if someone else wants to do it
while I'm sleeping that's fine too. :)
regards,
dan carpenter
prev parent reply other threads:[~2012-12-04 22:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-03 13:20 [PATCH] line6: Use kmemdup rather than duplicating its implementation Laurent Navet
2012-12-03 16:34 ` [Line6linux-devel] " Stefan Hajnoczi
2012-12-04 21:22 ` Markus Grabner
2012-12-04 21:29 ` Greg Kroah-Hartman
2012-12-04 22:25 ` Dan Carpenter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121204222529.GK6568@mwanda \
--to=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=laurent.navet@gmail.com \
--cc=line6linux-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).