Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fou: No permitir 0 para FOU_ATTR_IPPROTO.<br /> <br /> fou_udp_recv() tiene el mismo problema mencionado en el parche anterior.<br /> <br /> Si FOU_ATTR_IPPROTO se establece en 0, skb no es liberado por fou_udp_recv() ni &amp;#39;reenviado&amp;#39; en ip_protocol_deliver_rcu().<br /> <br /> Prohibamos 0 para FOU_ATTR_IPPROTO.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): desanclar URL en error de usb_submit_urb()<br /> <br /> En el commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): corregir fuga de memoria de URB"), el URB fue re-anclado antes de usb_submit_urb() en gs_usb_receive_bulk_callback() para prevenir una fuga de este URB durante la limpieza.<br /> <br /> Sin embargo, este parche no tuvo en cuenta que usb_submit_urb() podría fallar. El URB permanece anclado y usb_kill_anchored_urbs(&amp;amp;parent-&amp;gt;rx_submitted) en gs_can_close() entra en un bucle infinito ya que la lista de anclajes nunca queda vacía.<br /> <br /> Para corregir el error, desanclar el URB cuando ocurre un error de usb_submit_urb(), también imprimir un mensaje de información.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: esd_usb: esd_usb_read_bulk_callback(): corregir fuga de memoria de URB<br /> <br /> Corregir fuga de memoria similar a la del commit 7352e1d5932a (&amp;#39;can: gs_usb: gs_usb_receive_bulk_callback(): corregir fuga de memoria de URB&amp;#39;).<br /> <br /> En esd_usb_open(), los URB para transferencias USB de entrada son asignados, añadidos al ancla dev-&amp;gt;rx_submitted y enviados. En la función de devolución de llamada completa esd_usb_read_bulk_callback(), los URB son procesados y reenviados. En esd_usb_close(), los URB son liberados llamando a usb_kill_anchored_urbs(&amp;amp;dev-&amp;gt;rx_submitted).<br /> <br /> Sin embargo, esto no tiene en cuenta que el framework USB desancla el URB antes de que se llame a la función completa. Esto significa que una vez que un URB de entrada ha sido completado, ya no está anclado y finalmente no es liberado en esd_usb_close().<br /> <br /> Corregir la fuga de memoria anclando el URB en esd_usb_read_bulk_callback() al ancla dev-&amp;gt;rx_submitted.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: rsi: Corrección de corrupción de memoria debido a que no se estableció el tamaño de los datos del controlador vif<br /> <br /> La estructura ieee80211_vif contiene espacio adicional para los datos del controlador vif, cuando se asigna la estructura ieee80211_vif, el tamaño total de memoria que se asigna es sizeof(struct ieee80211_vif) + tamaño de los datos del controlador vif. El tamaño de los datos del controlador vif es establecido por cada controlador WiFi según sea necesario.<br /> <br /> El controlador RSI911x no establece el tamaño de los datos del controlador vif, por lo tanto, no se asigna espacio adicional para los datos del controlador vif más allá de la estructura ieee80211_vif. Sin embargo, el controlador RSI911x utiliza los datos del controlador vif para almacenar su estructura de datos del controlador vif &amp;#39;struct vif_priv&amp;#39;. Un acceso a vif-&amp;gt;drv_priv conduce a un acceso fuera de los límites de la estructura ieee80211_vif y a la corrupción de parte de la memoria.<br /> <br /> En caso de la falla observada localmente, rsi_mac80211_add_interface() escribiría struct vif_priv *vif_info = (struct vif_priv *)vif-&amp;gt;drv_priv; vif_info-&amp;gt;vap_id = vap_idx. Esta escritura corrompe el miembro de la estructura fq_tin struct list_head new_flows. El flow = list_first_entry(head, struct fq_flow, flowchain); en fq_tin_reset() luego reporta una dirección falsa no-NULL, que al ser accedida causa un fallo.<br /> <br /> El disparador es muy simple, arrancar la máquina con init=/bin/sh, montar devtmpfs, sysfs, procfs, y luego ejecutar &amp;#39;ip link set wlan0 up&amp;#39;, &amp;#39;sleep 1&amp;#39;, &amp;#39;ip link set wlan0 down&amp;#39; y el fallo ocurre.<br /> <br /> Solucionar esto estableciendo el tamaño correcto de los datos del controlador vif, que es el tamaño de &amp;#39;struct vif_priv&amp;#39;, para que se asigne memoria y el controlador pueda almacenar sus datos de controlador en ella, en lugar de corromper la memoria a su alrededor.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: phy: intel-xway: solucionar fuga de contador de referencias de nodo OF<br /> <br /> Una revisión automatizada detectó una fuga en el contador de referencias de un nodo OF al verificar si el nodo hijo &amp;#39;leds&amp;#39; existe.<br /> <br /> Llamar a of_put_node() para mantener correctamente el contador de referencias.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: mcba_usb: mcba_usb_read_bulk_callback(): corrige la fuga de memoria de URB<br /> <br /> Corrige una fuga de memoria similar a la del commit 7352e1d5932a (&amp;#39;can: gs_usb: gs_usb_receive_bulk_callback(): corrige la fuga de memoria de URB&amp;#39;).<br /> <br /> En mcba_usb_probe() -&amp;gt; mcba_usb_start(), los URB para transferencias USB de entrada se asignan, se añaden al ancla priv-&amp;gt;rx_submitted y se envían. En la función de callback de completado mcba_usb_read_bulk_callback(), los URB se procesan y se reenvían. En mcba_usb_close() -&amp;gt; mcba_urb_unlink(), los URB se liberan llamando a usb_kill_anchored_urbs(&amp;amp;priv-&amp;gt;rx_submitted).<br /> <br /> Sin embargo, esto no tiene en cuenta que el framework USB desancla el URB antes de que se llame a la función de completado. Esto significa que una vez que un URB de entrada ha sido completado, ya no está anclado y finalmente no se libera en usb_kill_anchored_urbs().<br /> <br /> Corrige la fuga de memoria anclando el URB en mcba_usb_read_bulk_callback() al ancla priv-&amp;gt;rx_submitted.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gpio: cdev: Corregir fugas de recursos ante errores en lineinfo_changed_notify()<br /> <br /> En las rutas de manejo de errores, lineinfo_changed_notify() no libera los recursos asignados, lo que provoca fugas. Corregirlo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: scarlett2: Corrección de desbordamiento de búfer en la recuperación de configuración<br /> <br /> La función scarlett2_usb_get_config() tiene un error lógico en el código de conversión de endianness que puede causar desbordamientos de búfer cuando count &amp;gt; 1.<br /> <br /> El código comprueba &amp;#39;if (size == 2)&amp;#39; donde &amp;#39;size&amp;#39; es el tamaño total del búfer en bytes, luego itera &amp;#39;count&amp;#39; veces tratando cada elemento como u16 (2 bytes). Esto hace que el bucle acceda a &amp;#39;count * 2&amp;#39; bytes cuando el búfer solo tiene &amp;#39;size&amp;#39; bytes asignados.<br /> <br /> Solución comprobando el tamaño del elemento (config_item-&amp;gt;size) en lugar del tamaño total del búfer. Esto asegura que la conversión de endianness coincida con el tipo de elemento real.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: ctxfi: Corrección de posible acceso OOB en el manejo del mezclador de audio<br /> <br /> En el código de manejo del mezclador de audio del controlador ctxfi, el campo &amp;#39;conf&amp;#39; se utiliza como una especie de índice de bucle, y se hace referencia a él en las retrollamadas de índice (amixer_index() y sum_index()).<br /> <br /> Como fue detectado recientemente por fuzzers, el código actual causa acceso OOB en esas funciones.<br /> | UBSAN: índice de array fuera de límites en /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48<br /> | el índice 8 está fuera de rango para el tipo &amp;#39;unsigned char [8]&amp;#39;<br /> <br /> Después del análisis, se encontró que la causa era la falta de la inicialización (o reinicialización) adecuada del campo &amp;#39;conj&amp;#39;.<br /> <br /> Este parche aborda esos accesos OOB añadiendo las inicializaciones adecuadas de los índices de bucle.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: Forzar que teql solo pueda ser usado como qdisc raíz<br /> <br /> La intención del diseño de teql es que solo se supone que debe ser usado como qdisc raíz.<br /> Necesitamos verificar esa restricción.<br /> <br /> Aunque no es importante, describiré el escenario que desenterró este problema para los curiosos.<br /> <br /> GangMin Kim logró idear un escenario de la siguiente manera:<br /> <br /> qdisc RAÍZ 1:0 (QFQ)<br /> ??? clase 1:1 (peso=15, lmax=16384) netem con retardo de 6.4s<br /> ??? clase 1:2 (peso=1, lmax=1514) teql<br /> <br /> GangMin envía un paquete que es encolado a 1:1 (netem).<br /> Cualquier invocación de desencolado por QFQ desde esta clase no devolverá un paquete hasta después de 6.4s. Mientras tanto, un segundo paquete es enviado y aterriza en 1:2. El encolado de teql devolverá éxito y esto activará la clase 1:2. El problema principal es que teql solo actualiza el qlen visible del padre (sch-&amp;gt;q.qlen) al desencolar. Dado que QFQ solo llamará a desencolar si peek tiene éxito (y el peek de teql siempre devuelve NULL), desencolar nunca será llamado y, por lo tanto, el qlen permanecerá como 0. Con eso en mente, cuando GangMin actualiza el valor lmax de 1:2, qfq_change_class llama a qfq_deact_rm_from_agg. Dado que el qlen del qdisc hijo no fue incrementado, qfq falla al desactivar la clase, pero aún así libera sus punteros del agregado. Así, cuando el primer paquete es reprogramado después de 6.4 segundos (el retardo de netem), se accede a un puntero colgante causando un UAF de GangMin.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mm/vma: corrige UAF de anon_vma en mremap() con fusión de VMA faulted y unfaulted Serie de parches "mm/vma: corrige UAF de anon_vma en mremap() con fusión de VMA faulted y unfaulted", v2. El commit 879bca0a2c4f (&amp;#39;mm/vma: corrige fusiones de VMA anónimas incorrectamente denegadas&amp;#39;) introdujo la capacidad de fusionar escenarios de fusión de VMA previamente no disponibles. Sin embargo, está manejando las fusiones incorrectamente cuando se trata de mremap() de un VMA faulted adyacente a un VMA unfaulted. Los problemas surgen en tres casos: 1. VMA anterior unfaulted:copiado -----| v .............| | unfaulted |(VMA faulted)| .............| anterior 2. Siguiente VMA unfaulted:copiado -----| v |(VMA faulted)| unfaulted | siguiente 3. Ambos VMA adyacentes unfaulted:copiado -----| v ............. | unfaulted |(VMA faulted)| unfaulted | ............. anterior siguiente Esta serie corrige cada uno de estos casos e introduce auto-pruebas para afirmar que los problemas están corregidos. También pruebo un caso adicional que ya estaba manejado, para afirmar que mis cambios continúan manejándolo correctamente: 4. anterior unfaulted, siguiente faulted:copiado -----| v ............. | unfaulted |(VMA faulted)| faulted | ............. anterior siguiente Este error fue descubierto a través de un informe de syzbot, enlazado en el primer parche de la serie, confirmé que esta serie corrige el error. También descubrí que no estamos verificando que el VMA faulted no fue bifurcado al fusionar un VMA copiado en los casos 1-3 anteriores, un problema que esta serie también aborda. También agregué auto-pruebas para afirmar que esto está resuelto (y confirmé que las pruebas fallaron antes de esto). También limpié vma_expand() como parte de este trabajo, renombré vma_had_uncowed_parents() a vma_is_fork_child() ya que el nombre anterior era indebidamente confuso, y simplifiqué los comentarios alrededor de esta función. Este parche (de 4): El commit 879bca0a2c4f (&amp;#39;mm/vma: corrige fusiones de VMA anónimas incorrectamente denegadas&amp;#39;) introdujo la capacidad de fusionar escenarios de fusión de VMA previamente no disponibles. La pieza clave de lógica introducida fue la capacidad de fusionar un VMA faulted inmediatamente adyacente a un VMA unfaulted, lo cual se basa en dup_anon_vma() para manejar correctamente el estado de anon_vma. En el caso de la fusión de un VMA existente (es decir, cambiando propiedades de un VMA y luego fusionando si esas propiedades son compartidas por VMA adyacentes), dup_anon_vma() se invoca correctamente. Sin embargo, en el caso de la fusión de un nuevo VMA, se pasó por alto un caso particular peculiar de mremap(). El problema es que vma_expand() solo realiza dup_anon_vma() si el objetivo (el VMA que finalmente se convertirá en el VMA fusionado): no es el siguiente VMA, es decir, el que aparece después del rango en el que se establecerá el nuevo VMA. Una idea clave aquí es que en todos los demás casos, aparte de mremap(), una nueva fusión de VMA o bien expande un VMA existente, lo que significa que el VMA objetivo será ese VMA, o anon_vma sería NULL. Específicamente: * __mmap_region() - no hay anon_vma en su lugar, mapeo inicial. * do_brk_flags() - expandiendo un VMA existente. * vma_merge_extend() - expandiendo un VMA existente. * relocate_vma_down() - no hay anon_vma en su lugar, mapeo inicial. Además, nos encontramos en la situación única de necesitar duplicar el estado de anon_vma de un VMA que no es ni el VMA anterior ni el siguiente con el que se está fusionando. dup_anon_vma() se ocupa exclusivamente del caso objetivo=unfaulted, fuente=faulted. Esto deja cuatro posibilidades, en cada caso donde el VMA copiado es faulted: 1. VMA anterior unfaulted:copiado -----| ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> vsock/virtio: soluciona un posible desbordamiento negativo en virtio_transport_get_credit()<br /> <br /> El cálculo de crédito en virtio_transport_get_credit() utiliza aritmética sin signo:<br /> <br /> ret = vvs-&amp;gt;peer_buf_alloc - (vvs-&amp;gt;tx_cnt - vvs-&amp;gt;peer_fwd_cnt);<br /> <br /> Si el par reduce su búfer anunciado (peer_buf_alloc) mientras hay bytes en tránsito, la resta puede sufrir un desbordamiento negativo y producir un valor positivo grande, lo que podría permitir que se pongan en cola más datos de los que el par puede manejar.<br /> <br /> Reutilizar virtio_transport_has_space() que ya maneja este caso y añadir un comentario para dejar claro por qué lo estamos haciendo.<br /> <br /> [Stefano: usar virtio_transport_has_space() en lugar de duplicar el código]<br /> [Stefano: ajustar el mensaje de commit]