Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
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 thesupplied `data[0]` value is a valid copy from user memory. It will atleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in"comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements areallocated. However, if `insn->n` is 0 (which is allowable for`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may containuninitialized data, and certainly contains invalid data, possibly from adifferent instruction in the array of instructions handled by`do_insnlist_ioctl()`. This will result in an incorrect value beingwritten to the digital output channel (or to the digital input/outputchannel if configured as an output), and may be reflected in theinternal saved state of the channel.Fix it by returning 0 early if `insn->n` is 0, before reaching the codethat accesses `data[0]`. Previously, the function always returned 1 onsuccess, but it is supposed to be the number of data samples actuallyread or written up to `insn->n`, which is 0 in this case.
No PoCs from references.
- https://github.com/w4zu/Debian_security