In the Linux kernel, the following vulnerability has been resolved: comedi: Fix use of uninitialized data in insnrwemulatebits() 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 "comedifops.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.