On 30/10/18 22:27, Spencer Olson wrote:
On Tue, Oct 30, 2018 at 6:21 AM Ian Abbott <abbo...@mev.co.uk> wrote:

On 25/10/18 02:36, Spencer E. Olson wrote:
Changes do_insn*_ioctl functions to allow for data lengths for each
comedi_insn of up to 2^16.  This patch also changes these functions to only
allocate as much memory as is necessary for each comedi_insn, rather than
allocating a fixed-sized scratch space.

In testing some user-space code for the new INSN_DEVICE_CONFIG_GET_ROUTES
facility with some newer hardware, I discovered that do_insn_ioctl and
do_insnlist_ioctl limited the amount of data that can be passed into the
kernel for insn's to a length of 256.  For some newer hardware, the number
of routes can be greater than 1000.  Working around the old limits (256)
would complicate the user-space/kernel interaction.

The new upper limit is reasonable with current memory available and does
not otherwise impact the memory footprint for any current or otherwise
typical configuration.
[snip]
There are still some broken drivers that do not check insn->n and assume
the data has some minimum length, so we will need to make the data array
some minimum length (say 16 * sizeof(unsigned int)) until those drivers
have been fixed.


I don't think that would be much of a problem, since 16*sizeof(uint)
is pretty negligible.  How certain are you that we would not have to
make that higher, as the previous default was a length of
256*sizeof(uint)?  It'll take me a day or two to resubmit (have other
things pressing on my time).

ai_config_master_clock() in cb_pcidas64.c is the worst offender of using unchecked data[] length, and that only uses a data[] length of 5. I've checked all the insn_read, insn_write, and insn_config handlers now and found a couple more drivers with the problem of potentially using data[] members beyond insn->n-1. These are "s626.c" and "addi_apci_3501.c". (The previously found files with the problem are "cb_pcidas64.c", "cb_pcidda.c", "ni_labpc_common.c", "ni_mio_common.c", and "s526.c". I've submitted patches for some of those, and will submit patches for the others sometime in the next few days.)

--
-=( Ian Abbott <abbo...@mev.co.uk> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268.  Registered address:    )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to