Vulnerabilidades

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 /> net: cpsw: Ejecutar la devolución de llamada ndo_set_rx_mode en una cola de trabajo<br /> <br /> El commit 1767bb2d47b7 (&amp;#39;ipv6: mcast: No retener RTNL para IPV6_ADD_MEMBERSHIP y MCAST_JOIN_GROUP.&amp;#39;) eliminó el bloqueo RTNL para las operaciones IPV6_ADD_MEMBERSHIP y MCAST_JOIN_GROUP. Sin embargo, este cambio desencadenó el siguiente rastreo de llamadas en mi placa BeagleBone Black:<br /> WARNING: net/8021q/vlan_core.c:236 en vlan_for_each+0x120/0x124, CPU#0: rpcbind/481<br /> RTNL: aserción fallida en net/8021q/vlan_core.c (236)<br /> Módulos enlazados:<br /> CPU: 0 UID: 997 PID: 481 Comm: rpcbind No contaminado 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT<br /> Nombre del hardware: Generic AM33XX (Flattened Device Tree)<br /> Rastreo de llamadas:<br /> unwind_backtrace desde show_stack+0x28/0x2c<br /> show_stack desde dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl desde __warn+0xb8/0x11c<br /> __warn desde warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt desde vlan_for_each+0x120/0x124<br /> vlan_for_each desde cpsw_add_mc_addr+0x54/0x98<br /> cpsw_add_mc_addr desde __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev desde __dev_mc_add+0x78/0x88<br /> __dev_mc_add desde igmp6_group_added+0x84/0xec<br /> igmp6_group_added desde __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc desde __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join desde do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt desde ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt desde do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt desde __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt desde ret_fast_syscall+0x0/0x54<br /> <br /> Este rastreo ocurre porque se llama a vlan_for_each() dentro de cpsw_ndo_set_rx_mode(), que espera que el bloqueo RTNL esté retenido. Dado que modificar vlan_for_each() para operar sin el bloqueo RTNL no es sencillo, y debido a que ndo_set_rx_mode() se invoca tanto con como sin el bloqueo RTNL a través de diferentes rutas de código, simplemente añadir rtnl_lock() en cpsw_ndo_set_rx_mode() no es una solución viable.<br /> <br /> Para resolver este problema, optamos por ejecutar el procesamiento real dentro de una cola de trabajo, siguiendo el enfoque utilizado por el controlador icssg-prueth.<br /> <br /> Tenga en cuenta: Para reproducir este problema, revertí manualmente los cambios en am335x-bone-common.dtsi del commit c477358e66a3 (&amp;#39;ARM: dts: am335x-bone: cambiar a nuevo controlador de switch cpsw&amp;#39;) para revertir al controlador cpsw heredado.

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 /> 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 /> wifi: mac80211: ocb: omitir rx_no_sta cuando la interfaz no está unida<br /> <br /> ieee80211_ocb_rx_no_sta() asume un contexto de canal válido, el cual solo está presente después de JOIN_OCB.<br /> <br /> RX puede ejecutarse antes de que se ejecute JOIN_OCB, en cuyo caso la interfaz OCB no está operativa. Omitir el manejo de pares RX cuando la interfaz no está unida para evitar advertencias en la ruta RX.

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.