In the Linux kernel, the following vulnerability has been resolved:
comedi: Fix use of uninitialized data in insn_rw_emulate_bits()
For Comedi INSN_READ and INSN_WRITE instructions on "digital"
subdevices (subdevice types COMEDI_SUBD_DI, COMEDI_SUBD_DO, and
COMEDI_SUBD_DIO), it is common for the subdevice driver not to have
insn_read and insn_write handler functions, but to have an
insn_bits handler function for handling Comedi INSN_BITS
instructions. In that case, the subdevice's insn_read and/or
insn_write function handler pointers are set to point to the
insn_rw_emulate_bits() function by __comedi_device_postconfig().
For INSN_WRITE, insn_rw_emulate_bits() currently assumes that the
supplied data[0] value is a valid copy from user memory. It will at
least exist because do_insnlist_ioctl() and do_insn_ioctl() in
"comedi_fops.c" ensure at lease MIN_SAMPLES (16) elements are
allocated. However, if insn->n is 0 (which is allowable for
INSN_READ and INSN_WRITE instructions, then data[0] may contain
uninitialized data, and certainly contains invalid data, possibly from a
different instruction in the array of instructions handled by
do_insnlist_ioctl(). This will result in an incorrect value being
written to the digital output channel (or to the digital input/output
channel if configured as an output), and may be reflected in the
internal saved state of the channel.
Fix it by returning 0 early if insn->n is 0, before reaching the code
that accesses data[0]. Previously, the function always returned 1 on
success, but it is supposed to be the number of data samples actually
read or written up to insn->n, which is 0 in this case.