Vulnerabilidad en kernel de Linux (CVE-2025-38480)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: Se corrige el uso de datos no inicializados en insn_rw_emulate_bits(). Para las instrucciones `INSN_READ` e `INSN_WRITE` de Comedi en subdispositivos "digitales" (tipos de subdispositivo `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO` y `COMEDI_SUBD_DIO`), es común que el controlador del subdispositivo no tenga las funciones de controlador `insn_read` e `insn_write`, sino una función de controlador `insn_bits` para manejar las instrucciones `INSN_BITS` de Comedi. En ese caso, los punteros del controlador de función `insn_read` y/o `insn_write` del subdispositivo se configuran para apuntar a la función `insn_rw_emulate_bits()` mediante `__comedi_device_postconfig()`. Para `INSN_WRITE`, `insn_rw_emulate_bits()` actualmente asume que el valor `data[0]` proporcionado es una copia válida de la memoria del usuario. Al menos existirá porque `do_insnlist_ioctl()` y `do_insn_ioctl()` en "comedi_fops.c" garantizan la asignación de al menos `MIN_SAMPLES` (16) elementos. Sin embargo, si `insn->n` es 0 (lo cual es permitido para las instrucciones `INSN_READ` e `INSN_WRITE`, entonces `data[0]` puede contener datos no inicializados, y ciertamente contiene datos no válidos, posiblemente de una instrucción diferente en la matriz de instrucciones manejadas por `do_insnlist_ioctl()`. Esto dará como resultado que se escriba un valor incorrecto en el canal de salida digital (o en el canal de entrada/salida digital si se configura como una salida), y puede reflejarse en el estado guardado interno del canal. Arréglelo devolviendo 0 temprano si `insn->n` es 0, antes de llegar al código que accede a `data[0]`. Anteriormente, la función siempre devolvía 1 en caso de éxito, pero se supone que es el número de muestras de datos realmente leídas o escritas hasta `insn->n`, que es 0 en este caso.