Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm, shmem: evitar bucle infinito en una condición de carrera de truncamiento<br /> <br /> Al truncar una entrada de intercambio grande, shmem_free_swap() devuelve 0 cuando el índice de la entrada no coincide con el índice dado debido a la alineación de búsqueda. La ruta de retroceso en caso de fallo comprueba si la entrada cruza el borde final y aborta cuando esto ocurre, por lo que el truncamiento no borrará una entrada o rango inesperado. Pero un escenario fue ignorado.<br /> <br /> Cuando &amp;#39;index&amp;#39; apunta al medio de una entrada de intercambio grande, y la entrada de intercambio grande no cruza el borde final, find_get_entries() devolverá esa entrada de intercambio grande como el primer elemento en el lote con &amp;#39;indices[0]&amp;#39; igual a &amp;#39;index&amp;#39;. El índice base de la entrada será menor que &amp;#39;indices[0]&amp;#39;, por lo que shmem_free_swap() fallará y devolverá 0 debido a la comprobación "base &amp;lt; index". El código entonces llamará a shmem_confirm_swap(), obtendrá el orden, comprobará si cruza el límite END (lo cual no hace), y reintentará con el mismo índice.<br /> <br /> La siguiente iteración encontrará la misma entrada de nuevo en el mismo índice con los mismos índices, lo que lleva a un bucle infinito.<br /> <br /> Solucione esto reintentando con un índice redondeado a la baja, y abortar si el índice es menor que el rango de truncamiento.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> HID: i2c-hid: corrige un potencial desbordamiento de búfer en i2c_hid_get_report()<br /> <br /> &amp;#39;i2c_hid_xfer&amp;#39; se utiliza para leer &amp;#39;recv_len + sizeof(__le16)&amp;#39; bytes de datos en &amp;#39;ihid-&amp;gt;rawbuf&amp;#39;.<br /> <br /> El primero puede provenir del espacio de usuario en el controlador hidraw y está limitado únicamente por HID_MAX_BUFFER_SIZE(16384) por defecto (a menos que también configuremos el campo &amp;#39;max_buffer_size&amp;#39; de &amp;#39;struct hid_ll_driver&amp;#39;, lo cual no hacemos).<br /> <br /> El segundo tiene un tamaño determinado en tiempo de ejecución por el tamaño máximo de los diferentes tipos de informes que se podrían recibir en cualquier dispositivo particular y puede ser un valor mucho menor.<br /> <br /> Esto se soluciona truncando &amp;#39;recv_len&amp;#39; a &amp;#39;ihid-&amp;gt;bufsize - sizeof(__le16)&amp;#39;.<br /> <br /> El impacto es bajo ya que el acceso a los dispositivos hidraw requiere root.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvmet-tcp: corregir cuelgue en nvmet_tcp_listen_data_ready()<br /> <br /> Cuando el socket se cierra mientras está en TCP_LISTEN, se ejecuta una devolución de llamada para vaciar todos los paquetes pendientes, lo que a su vez llama a nvmet_tcp_listen_data_ready() con el sk_callback_lock retenido. Así que necesitamos verificar si estamos en TCP_LISTEN antes de intentar obtener el sk_callback_lock() para evitar un interbloqueo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dpaa2-switch: añadir comprobación de límites para if_id en el manejador IRQ<br /> <br /> El manejador IRQ extrae if_id de los 16 bits superiores del registro de estado del hardware y lo utiliza para indexar en ethsw-&amp;gt;ports[] sin validación. Dado que if_id puede ser cualquier valor de 16 bits (0-65535) pero el array de puertos solo se asigna con elementos sw_attr.num_ifs, esto puede llevar a una posible lectura fuera de límites.<br /> <br /> Añadir una comprobación de límites antes de acceder al array, consistente con la validación existente en dpaa2_switch_rx().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: sincronizar la lectura del superbloque del disco y establecer el tamaño de bloque<br /> <br /> Cuando el usuario realiza un montaje btrfs, el dispositivo de bloques no se configura correctamente. El usuario establece el tamaño de bloque del dispositivo de bloques a 0x4000 ejecutando el comando BLKBSZSET.<br /> Dado que el cambio de tamaño de bloque también modifica el valor de mapping-&amp;gt;flags, esto afecta aún más el resultado del cálculo de mapping_min_folio_order().<br /> <br /> Analicemos los dos escenarios siguientes:<br /> <br /> Escenario 1: Sin ejecutar el comando BLKBSZSET, el tamaño de bloque es 0x1000, y mapping_min_folio_order() devuelve 0;<br /> <br /> Escenario 2: Después de ejecutar el comando BLKBSZSET, el tamaño de bloque es 0x4000, y mapping_min_folio_order() devuelve 2.<br /> <br /> do_read_cache_folio() asigna un folio antes de que se ejecute el comando BLKBSZSET. Esto resulta en que el folio asignado tiene un valor de orden de 0. Posteriormente, después de ejecutar BLKBSZSET, el tamaño de bloque aumenta a 0x4000, y el resultado del cálculo de mapping_min_folio_order() se convierte en 2.<br /> <br /> Esto conduce a dos consecuencias indeseables:<br /> <br /> 1. filemap_add_folio() activa una aserción VM_BUG_ON_FOLIO(folio_order(folio) &amp;lt; mapping_min_folio_order(mapping)).<br /> <br /> 2. El informe de syzbot [1] muestra una desreferencia de puntero nulo en create_empty_buffers() debido a un fallo en la asignación de un buffer head.<br /> <br /> Se debe establecer una sincronización basada en el inodo entre el comando BLKBSZSET y la página de caché de lectura para evitar inconsistencias en el tamaño de bloque o las banderas de mapeo antes y después de la asignación de folio.<br /> <br /> [1]<br /> KASAN: desreferencia de puntero nulo en el rango [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694<br /> Rastro de Llamada:<br /> folio_create_buffers+0x109/0x150 fs/buffer.c:1802<br /> block_read_full_folio+0x14c/0x850 fs/buffer.c:2403<br /> filemap_read_folio+0xc8/0x2a0 mm/filemap.c:2496<br /> do_read_cache_folio+0x266/0x5c0 mm/filemap.c:4096<br /> do_read_cache_page mm/filemap.c:4162 [inline]<br /> read_cache_page_gfp+0x29/0x120 mm/filemap.c:4195<br /> btrfs_read_disk_super+0x192/0x500 fs/btrfs/volumes.c:1367

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: tegra: Corrección de una fuga de memoria en tegra_slink_probe()<br /> <br /> En tegra_slink_probe(), cuando platform_get_irq() falla, retorna directamente de la función con un código de error, lo que provoca una fuga de memoria.<br /> <br /> Reemplazarlo con una etiqueta goto para garantizar una limpieza adecuada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb/server: corregir fuga de contador de referencias en smb2_open()<br /> <br /> Cuando ksmbd_vfs_getattr() falla, el contador de referencias de ksmbd_file debe ser liberado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb/servidor: corregir fuga de contador de referencias en parse_durable_handle_context()<br /> <br /> Cuando el comando es una operación de repetición y se devuelve -ENOEXEC,<br /> el contador de referencias de ksmbd_file debe ser liberado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: wlcore: asegurar el headroom de skb antes de skb_push<br /> <br /> Esto evita Oops ocasionales de skb_under_panic de wl1271_tx_work. En este caso, el headroom es menor de lo necesario (típicamente 110 - 94 = 16 bytes).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb/servidor: llamar a ksmbd_session_rpc_close() en la ruta de error en create_smb2_pipe()<br /> <br /> Cuando ksmbd_iov_pin_rsp() falla, deberíamos llamar a ksmbd_session_rpc_close().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> riscv: Sanitizar la indexación de la tabla de llamadas al sistema bajo especulación<br /> <br /> El número de llamada al sistema es un valor controlado por el usuario utilizado para indexar la tabla de llamadas al sistema. Usar array_index_nospec() para restringir este valor después de la comprobación de límites para prevenir el acceso especulativo fuera de límites y la posterior fuga de datos a través de canales laterales de caché.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: mmp_pdma: Corrección de condición de carrera en mmp_pdma_residue()<br /> <br /> Añadir bloqueo adecuado en mmp_pdma_residue() para prevenir uso después de liberación al acceder a la lista de descriptores y al contenido del descriptor.<br /> <br /> La condición de carrera ocurre cuando múltiples hilos llaman a tx_status() mientras el tasklet en otra CPU está liberando descriptores completados:<br /> <br /> CPU 0 CPU 1<br /> ----- -----<br /> mmp_pdma_tx_status()<br /> mmp_pdma_residue()<br /> -&amp;gt; SIN BLOQUEO mantenido<br /> list_for_each_entry(sw, ..)<br /> Interrupción DMA<br /> dma_do_tasklet()<br /> -&amp;gt; spin_lock(&amp;amp;desc_lock)<br /> list_move(sw-&amp;gt;node, ...)<br /> spin_unlock(&amp;amp;desc_lock)<br /> | dma_pool_free(sw) &amp;lt;- ¡LIBERADO!<br /> -&amp;gt; acceso a sw-&amp;gt;desc &amp;lt;- ¡UAF!<br /> <br /> Este problema puede ser reproducido al ejecutar dmatest en el mismo canal con múltiples hilos (hilos_por_canal &amp;gt; 1).<br /> <br /> Solución protegiendo la iteración de la lista chain_running y el acceso al descriptor con el spinlock chan-&amp;gt;desc_lock.