From: Johan Hovold <johan@kernel.org>
To: Ian Abbott <abbotti@mev.co.uk>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 2/5] comedi: dt9812: fix DMA buffers on stack
Date: Wed, 27 Oct 2021 11:05:45 +0200 [thread overview]
Message-ID: <YXkWaREjhd1+Law+@hovoldconsulting.com> (raw)
In-Reply-To: <ecdee752-72c3-c48a-fee2-49dccf115d71@mev.co.uk>
On Tue, Oct 26, 2021 at 03:27:13PM +0100, Ian Abbott wrote:
> On 25/10/2021 12:45, Johan Hovold wrote:
> > USB transfer buffers are typically mapped for DMA and must not be
> > allocated on the stack or transfers will fail.
> >
> > Allocate proper transfer buffers in the various command helpers and
> > return an error on short transfers instead of acting on random stack
> > data.
> >
> > Note that this also fixes a stack info leak on systems where DMA is not
> > used as 32 bytes are always sent to the device regardless of how short
> > the command is.
> >
> > Fixes: 63274cd7d38a ("Staging: comedi: add usb dt9812 driver")
> > Cc: stable@vger.kernel.org # 2.6.29
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> > drivers/comedi/drivers/dt9812.c | 109 ++++++++++++++++++++++++--------
> > 1 file changed, 82 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/comedi/drivers/dt9812.c b/drivers/comedi/drivers/dt9812.c
> > index 634f57730c1e..f15c306f2d06 100644
> > --- a/drivers/comedi/drivers/dt9812.c
> > +++ b/drivers/comedi/drivers/dt9812.c
> > @@ -32,6 +32,7 @@
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > #include <linux/errno.h>
> > +#include <linux/slab.h>
> > #include <linux/uaccess.h>
> >
> > #include "../comedi_usb.h"
> > @@ -237,22 +238,41 @@ static int dt9812_read_info(struct comedi_device *dev,
> > {
> > struct usb_device *usb = comedi_to_usb_dev(dev);
> > struct dt9812_private *devpriv = dev->private;
> > - struct dt9812_usb_cmd cmd;
> > + struct dt9812_usb_cmd *cmd;
> > int count, ret;
> > + u8 *tbuf;
> >
> > - cmd.cmd = cpu_to_le32(DT9812_R_FLASH_DATA);
> > - cmd.u.flash_data_info.address =
> > + cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
> > + if (!cmd)
> > + return -ENOMEM;
> > +
> > + cmd->cmd = cpu_to_le32(DT9812_R_FLASH_DATA);
> > + cmd->u.flash_data_info.address =
> > cpu_to_le16(DT9812_DIAGS_BOARD_INFO_ADDR + offset);
> > - cmd.u.flash_data_info.numbytes = cpu_to_le16(buf_size);
> > + cmd->u.flash_data_info.numbytes = cpu_to_le16(buf_size);
> >
> > /* DT9812 only responds to 32 byte writes!! */
> > ret = usb_bulk_msg(usb, usb_sndbulkpipe(usb, devpriv->cmd_wr.addr),
> > - &cmd, 32, &count, DT9812_USB_TIMEOUT);
> > + cmd, sizeof(*cmd), &count, DT9812_USB_TIMEOUT);
> > + kfree(cmd);
> > if (ret)
> > return ret;
> >
> > - return usb_bulk_msg(usb, usb_rcvbulkpipe(usb, devpriv->cmd_rd.addr),
> > - buf, buf_size, &count, DT9812_USB_TIMEOUT);
> > + tbuf = kmalloc(buf_size, GFP_KERNEL);
> > + if (!tbuf)
> > + return -ENOMEM;
> > +
> > + ret = usb_bulk_msg(usb, usb_rcvbulkpipe(usb, devpriv->cmd_rd.addr),
> > + tbuf, buf_size, &count, DT9812_USB_TIMEOUT);
> > + if (!ret) {
> > + if (count == buf_size)
> > + memcpy(buf, tbuf, buf_size);
> > + else
> > + ret = -EREMOTEIO;
> > + }
> > + kfree(tbuf);
> > +
> > + return ret;
> > }
>
> I suggest doing all the allocations up front so it doesn't leave an
> unread reply message in the unlikely event that the tbuf allocation
> fails. (It could even allocate a single buffer for both the command and
> the reply since they are not needed at the same time.)
These small allocations will currently never fail, but if they ever were
to, there are other allocations done in the I/O path which would have
the same effect if they failed. And if this ever happens, you certainly
have bigger problems than worrying about the state of this device. :)
That said, I'll see if I can reuse a single buffer without things
getting too messy.
Johan
next prev parent reply other threads:[~2021-10-27 9:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 11:45 [PATCH 0/5] comedi: misc fixes Johan Hovold
2021-10-25 11:45 ` [PATCH 1/5] comedi: ni_usb6501: fix NULL-deref in command paths Johan Hovold
2021-10-26 14:12 ` Ian Abbott
2021-10-27 8:54 ` Johan Hovold
2021-10-25 11:45 ` [PATCH 2/5] comedi: dt9812: fix DMA buffers on stack Johan Hovold
2021-10-26 14:27 ` Ian Abbott
2021-10-27 9:05 ` Johan Hovold [this message]
2021-10-25 11:45 ` [PATCH 3/5] comedi: vmk80xx: fix transfer-buffer overflows Johan Hovold
2021-10-26 14:32 ` Ian Abbott
2021-10-25 11:45 ` [PATCH 4/5] comedi: vmk80xx: fix bulk-buffer overflow Johan Hovold
2021-10-26 14:34 ` Ian Abbott
2021-10-25 11:45 ` [PATCH 5/5] comedi: vmk80xx: fix bulk and interrupt message timeouts Johan Hovold
2021-10-26 14:35 ` Ian Abbott
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=YXkWaREjhd1+Law+@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=abbotti@mev.co.uk \
--cc=gregkh@linuxfoundation.org \
--cc=hsweeten@visionengravers.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.