This silences all the sparse warnings in intel_sst_app_interface.c.
It was just a matter of adding __user annotations, I didn't find any
real bugs here. Quite a few of these were needed for stuff I added
earlier, sorry about that.
I removed a couple casts to (void *) that caused a warning like:
drivers/staging/intel_sst/intel_sst_app_interface.c:606:27:
warning: cast removes address space of expression
For example sst_drv_ctx->mailbox is already declared as
"void __iomem *mailbox" so casting it to void pointer isn't necessary
and it makes sparse complain because it removes the __user attribute.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There were some places in intel_sst_mmap_play_capture() that
dereferenced user pointers instead of copying the data to the kernel.
I removed the BUG_ON(!mmap_buf) and BUG_ON(!buf_entry) since those are
never possible in the current code.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is another patch about copying data to the kernel before using it.
SNDRV_SST_STREAM_DECODE is sort of tricky because we need to do a
copy_from_user() that gives us another two pointers and we have copy
those. Those again give us some more pointers that we have to copy.
Besides those problems, the code had a stack overflow:
- struct snd_sst_buff_entry ibuf_temp[param->ibufs->entries],
- obuf_temp[param->obufs->entries];
param->ibufs->entries comes from the user.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is another patch about making a copy of the data into kernel space
before using it. It is easy to trigger a kernel oops in the original
code. If you passed a NULL to SNDRV_SST_SET_TARGET_DEVICE then it
called BUG_ON(). And SNDRV_SST_DRIVER_INFO would let you write the
information to arbitrary memory locations which is a security violation.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This code dereferences user supplied pointers directly instead of doing
a copy_from_user(). Some kernel configs put user and kernel memory in
different address spaces so this code isn't portable. Also the user
memory could be swapped out or in this case the pointer could just be
NULL leading to an oops.
Another thing is that it makes permission tests like this sort of
meaningless.
if (minor == STREAM_MODULE && rec_mute->stream_id == 0) {
retval = -EPERM;
break;
}
The user could set stream_id to 1 for the test and then change it later.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vinod wanted the copy_to_user() calls in this format:
if (copy_to_user())
retval = -EFAULT;
instead of this:
retval = copy_to_user();
if (retval)
retval = -EFAULt;
I've done that for the whole intel_sst_app_interface.c file. In the
process I noticed a couple more places that returned -EBUSY or -EAGAIN
instead of -EFAULT.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This should be >= instead of > or we go passed the end of the array.
Also the arrays are declared with size MAX_NUM_STREAMS. This is the
only place that uses MAX_NUM_STREAMS_MFLD. It seems like asking for
trouble to use two variables for the same information. I've changed
everything to use MAX_NUM_STREAMS.
This bug isn't really harmful. In the worst case, if you enabled
debugging then you would see a message.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
copy_to_user() returns the number of bytes remaining to be copied but we
want to return an error code. And that error code is -EFAULT not -EIO.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
&sst_drv_ctx->streams[str_id].lock and &stream->lock are the same.
The mutex_lock() uses &stream->lock so this makes things consistent and
it's nicer to read as well.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kernel locking in ioctl was introduced when ioctl function was
moved from ioctl to unlocked ioctl
This is no longer required hence removed
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
intel_sst_drv_interface.c uses msleep() so it needs to include delay.h:
drivers/staging/intel_sst/intel_sst_drv_interface.c:88: error: implicit declaration of function 'msleep'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As retval stores error code, it should be signed int.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
str_id was unsigned, so check for (str_id <= 0) made no sense.
Made it signed.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is the Intel SST audio driver.
As compared to the previous versions it has all the printks and other stuff
noted cleaned up and more hardware support. The Aava support is disabled in
this patch (is_aava resolves to 0) because the Aava board detection logic
is not yet upstream.
The driver itself is a combination of a traditional ALSA driver and a
hardware assisted offload driver which can play audio while the processor
is asleep but which can't do all the more interactive stuff.
In the general case most software would use the ALSA interface, but the
other interface is needed for certain classes of use such as music playback
on highly power consumption sensitive devices.
This is going to staging primarily because it depends upon the staging memrar
driver.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Harsha Priya <priya.harsha@intel.com>
[Merged together and tweaked for -next]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Carpenter