Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: act_api: evitar la desreferenciación de ERR_PTR en tcf_idrinfo_destroy<br /> <br /> syzbot informó de un fallo en tc_act_in_hw() durante el desmontaje de netns donde tcf_idrinfo_destroy() pasó un valor ERR_PTR(-EBUSY) como un puntero tc_action, lo que llevó a una desreferenciación inválida.<br /> <br /> Protegerse contra entradas ERR_PTR al iterar el IDR de acción para que el desmontaje no llame a tc_act_in_hw() en un puntero de error.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> nfsd: comprobar que el servidor está en ejecución en unlock_filesystem<br /> <br /> Si estamos intentando desbloquear el sistema de archivos a través de una interfaz de administración y nfsd no está en ejecución, se provoca la caída del servidor. Esto ocurre actualmente porque nfsd4_revoke_states() accede a estructuras de estado (por ejemplo, conf_id_hashtbl) que han sido liberadas como parte del apagado del servidor.<br /> <br /> [ 59.465072] Traza de llamada:<br /> [ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)<br /> [ 59.465830] write_unlock_fs+0x258/0x440 [nfsd]<br /> [ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd]<br /> [ 59.466780] vfs_write+0x1f0/0x938<br /> [ 59.467088] ksys_write+0xfc/0x1f8<br /> [ 59.467395] __arm64_sys_write+0x74/0xb8<br /> [ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8<br /> [ 59.468177] do_el0_svc+0x154/0x1d8<br /> [ 59.468489] el0_svc+0x40/0xe0<br /> [ 59.468767] el0t_64_sync_handler+0xa0/0xe8<br /> [ 59.469138] el0t_64_sync+0x1ac/0x1b0<br /> <br /> Asegurar que esto no pueda ocurrir tomando el nfsd_mutex y comprobando que el servidor sigue activo, y luego manteniendo el mutex durante la llamada a nfsd4_revoke_states().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: no escribir en msg_get_inq en el callee<br /> <br /> Corrección de desreferencia de puntero NULL.<br /> <br /> msg_get_inq es un campo de entrada del caller al callee. No lo establezca en el callee, ya que el caller podría no borrarlo al reutilizar la estructura.<br /> <br /> Esta es solo una variante interna del kernel de msghdr, y el único usuario reinicializa el campo. Por lo tanto, esto no es crítico por esa razón. Pero es más robusto evitar la escritura, y un código ligeramente más simple. Y corrige un error, ver abajo.<br /> <br /> Los callers establecen msg_get_inq para solicitar que la longitud de la cola de entrada sea devuelta en msg_inq. Esto es equivalente a, pero independiente de, la solicitud SO_INQ para devolver esa misma información como un cmsg (tp-&amp;gt;recvmsg_inq). Para reducir las bifurcaciones en la ruta crítica, el segundo también establece el msg_inq. Eso es WAI.<br /> <br /> Esta es una corrección para el commit 4d1442979e4a (&amp;#39;af_unix: no publicar cmsg para SO_INQ a menos que se solicite explícitamente&amp;#39;), que corrigió lo inverso.<br /> <br /> También evitar la desreferencia de puntero NULL en unix_stream_read_generic si state-&amp;gt;msg es NULL y se escribe msg-&amp;gt;msg_get_inq. Un state-&amp;gt;msg NULL puede ocurrir al hacer splicing a partir del commit 2b514574f7e8 (&amp;#39;net: af_unix: implementar splice para sockets af_unix de stream&amp;#39;).<br /> <br /> También colapsar dos ramas usando un OR bit a bit.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gpiolib: corrige condición de carrera para gdev-&amp;gt;srcu<br /> <br /> Si dos controladores estaban llamando a gpiochip_add_data_with_key(), uno podría estar recorriendo la lista protegida por srcu en gpio_name_to_desc(), mientras tanto, el otro acaba de añadir su gdev en gpiodev_add_to_list_unlocked(). Esto crea un marco de tiempo no mutexado y no protegido, cuando una instancia está desreferenciando y usando &amp;amp;gdev-&amp;gt;srcu, antes de que la otra lo haya inicializado, resultando en un fallo:<br /> <br /> [ 4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000<br /> [ 4.943396] Mem abort info:<br /> [ 4.943400] ESR = 0x0000000096000005<br /> [ 4.943403] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 4.943407] SET = 0, FnV = 0<br /> [ 4.943410] EA = 0, S1PTW = 0<br /> [ 4.943413] FSC = 0x05: level 1 translation fault<br /> [ 4.943416] Data abort info:<br /> [ 4.943418] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 4.946220] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 4.955261] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000<br /> [ 4.961449] [ffff800272bcc000] pgd=0000000000000000<br /> [ 4.969203] , p4d=1000000039739003<br /> [ 4.979730] , pud=0000000000000000<br /> [ 4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 para node "reset"<br /> [ 4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> ...<br /> [ 5.121359] pc : __srcu_read_lock+0x44/0x98<br /> [ 5.131091] lr : gpio_name_to_desc+0x60/0x1a0<br /> [ 5.153671] sp : ffff8000833bb430<br /> [ 5.298440]<br /> [ 5.298443] Call trace:<br /> [ 5.298445] __srcu_read_lock+0x44/0x98<br /> [ 5.309484] gpio_name_to_desc+0x60/0x1a0<br /> [ 5.320692] gpiochip_add_data_with_key+0x488/0xf00<br /> 5.946419] ---[ end trace 0000000000000000 ]---<br /> <br /> Mover el código de inicialización para los campos de gdev antes de que sea añadido a gpio_devices, con código de inicialización adyacente.<br /> Ajustar las sentencias goto para reflejar el orden de operaciones modificado<br /> <br /> [Bartosz: se corrigió un problema de compilación, se eliminó una nueva línea suelta]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nfsd: proporcionar bloqueo para v4_end_grace<br /> <br /> Escribir en v4_end_grace puede competir con el apagado del servidor y resultar en que la memoria sea accedida después de haber sido liberada - reclaim_str_hashtbl en particular.<br /> <br /> No podemos mantener nfsd_mutex durante la llamada a nfsd4_end_grace() ya que se mantiene mientras se llama a client_tracking_op-&amp;gt;init() y eso puede esperar una llamada ascendente a nfsdcltrack que puede escribir en v4_end_grace, resultando en un interbloqueo.<br /> <br /> nfsd4_end_grace() también es llamada por la cola de trabajo &amp;#39;landromat&amp;#39; y esto no requiere bloqueo ya que el apagado del servidor detendrá el trabajo y esperará por él antes de liberar cualquier cosa a la que nfsd4_end_grace() pudiera acceder.<br /> <br /> Sin embargo, debemos asegurarnos de que escribir en v4_end_grace no reinicie el elemento de trabajo después de que el apagado ya lo haya esperado. Para esto añadimos una nueva bandera protegida con nn-&amp;gt;client_lock. Se establece solo mientras es seguro realizar llamadas de seguimiento de cliente, y v4_end_grace solo programa trabajo mientras la bandera está establecida con el spinlock mantenido.<br /> <br /> Así, este parche añade un campo nfsd_net &amp;#39;client_tracking_active&amp;#39; que se establece como se describe. Otro campo &amp;#39;grace_end_forced&amp;#39;, se establece cuando se escribe en v4_end_grace. Después de que esto se establece, y siempre que client_tracking_active esté establecido, el &amp;#39;laundromat&amp;#39; es programado. Este campo &amp;#39;grace_end_forced&amp;#39; omite otras comprobaciones para determinar si el período de gracia ha terminado.<br /> <br /> Esto resuelve una condición de carrera que puede resultar en uso después de liberación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: prevenir posibles lecturas fuera de límites en handle_auth_done()<br /> <br /> Realizar una comprobación explícita de límites en payload_len para evitar un posible acceso fuera de límites en la llamada.<br /> <br /> [ idryomov: registro de cambios ]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> arp: no asumir que dev_hard_header() no cambia skb-&amp;gt;head<br /> <br /> arp_create() es el único llamador de dev_hard_header() que asume que skb-&amp;gt;head permanece sin cambios.<br /> <br /> Un commit reciente dejó de realizar esta suposición.<br /> <br /> Inicializar el puntero @arp después de la llamada a dev_hard_header().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: evitar la fuga de información del kernel de la estructura iw_point<br /> <br /> La estructura iw_point tiene un agujero de 32 bits en arquitecturas de 64 bits.<br /> <br /> struct iw_point {<br /> void __user *pointer; /* Puntero a los datos (en espacio de usuario) */<br /> __u16 length; /* número de campos o tamaño en bytes */<br /> __u16 flags; /* Parámetros opcionales */<br /> };<br /> <br /> Asegúrese de poner a cero la estructura para evitar la divulgación de 32 bits de datos del kernel al espacio de usuario.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: corrige fuga de memoria en skb_segment_list para paquetes GRO<br /> <br /> Cuando se llama a skb_segment_list() durante el reenvío de paquetes, maneja paquetes que fueron agregados por el motor GRO.<br /> <br /> Históricamente, la lógica de segmentación en skb_segment_list asume que los segmentos individuales se dividen de un SKB padre y pueden necesitar llevar su propia contabilidad de memoria de socket. En consecuencia, el código transfiere truesize del padre a los segmentos recién creados.<br /> <br /> Antes del commit ed4cccef64c1 (&amp;#39;gro: corrige transferencia de propiedad&amp;#39;), esta resta de truesize en skb_segment_list() era válida porque los fragmentos aún llevaban una referencia al socket original.<br /> <br /> Sin embargo, el commit ed4cccef64c1 (&amp;#39;gro: corrige transferencia de propiedad&amp;#39;) cambió este comportamiento al asegurar que las entradas de fraglist se huérfanan explícitamente (skb-&amp;gt;sk = NULL) para evitar un huérfano ilegal más adelante en la pila. Este cambio significó que la carga completa de memoria del socket permaneció con el SKB de cabecera, pero la lógica de contabilidad correspondiente en skb_segment_list() nunca se actualizó.<br /> <br /> Como resultado, el código actual añade incondicionalmente el truesize de cada fragmento a delta_truesize y lo resta del SKB padre. Dado que los fragmentos ya no se cargan al socket, esta resta resulta en un recuento insuficiente efectivo de memoria cuando se libera la cabecera. Esto hace que sk_wmem_alloc permanezca distinto de cero, impidiendo la destrucción del socket y provocando una fuga de memoria persistente.<br /> <br /> La fuga puede observarse a través de KMEMLEAK al desmantelar el entorno de red:<br /> <br /> objeto sin referencia 0xffff8881e6eb9100 (tamaño 2048):<br /> comm "ping", pid 6720, jiffies 4295492526<br /> rastreo:<br /> kmem_cache_alloc_noprof+0x5c6/0x800<br /> sk_prot_alloc+0x5b/0x220<br /> sk_alloc+0x35/0xa00<br /> inet6_create.part.0+0x303/0x10d0<br /> __sock_create+0x248/0x640<br /> __sys_socket+0x11b/0x1d0<br /> <br /> Dado que skb_segment_list() se utiliza exclusivamente para paquetes SKB_GSO_FRAGLIST construidos por GRO, el ajuste de truesize se elimina.<br /> <br /> La llamada a skb_release_head_state() debe conservarse. Como se documenta en el commit cf673ed0e057 (&amp;#39;net: corrige fuga de recuento de referencias de segmentación de fraglist&amp;#39;), todavía es necesario para descartar correctamente las referencias a extensiones SKB que pueden ser sobrescritas durante __copy_skb_header().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dm-verity: deshabilitar la corrección de errores hacia adelante recursiva<br /> <br /> Hay dos problemas con la corrección recursiva:<br /> <br /> 1. Puede causar una denegación de servicio. En fec_read_bufs, hay un bucle que tiene 253 iteraciones. Para cada iteración, podemos llamar a verity_hash_for_block recursivamente. Hay un límite de 4 recursiones anidadas, lo que significa que puede haber como máximo 253^4 (4 mil millones) iteraciones. El equipo de QE de Red Hat creó una imagen que lleva a dm-verity a este límite, y esta imagen simplemente hace que el proceso udev-worker se quede atascado en el estado &amp;#39;D&amp;#39;.<br /> <br /> 2. No funciona. En fec_read_bufs almacenamos datos en la variable &amp;#39;fio-&amp;gt;bufs&amp;#39;, pero fio bufs se comparte entre invocaciones recursivas; si &amp;#39;verity_hash_for_block&amp;#39; invocara la corrección recursivamente, sobrescribiría los fio-&amp;gt;bufs parcialmente llenos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: nf_tables: evitar la revalidación de cadenas si es posible<br /> <br /> Hamza Mahfooz informa de bloqueos suaves de CPU en<br /> nft_chain_validate():<br /> <br /> watchdog: BUG: soft lockup - CPU#1 atascada durante 27s! [iptables-nft-re:37547]<br /> [..]<br /> RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]<br /> [..]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_table_validate+0x6b/0xb0 [nf_tables]<br /> nf_tables_validate+0x8b/0xa0 [nf_tables]<br /> nf_tables_commit+0x1df/0x1eb0 [nf_tables]<br /> [..]<br /> <br /> Actualmente, nf_tables recorrerá toda la tabla (grafo de cadenas), comenzando<br /> desde los puntos de entrada (cadenas base), explorando todas las rutas posibles<br /> (saltos de cadena). Pero hay casos en los que podríamos evitar la revalidación.<br /> <br /> Considere:<br /> 1 input -&amp;gt; j2 -&amp;gt; j3<br /> 2 input -&amp;gt; j2 -&amp;gt; j3<br /> 3 input -&amp;gt; j1 -&amp;gt; j2 -&amp;gt; j3<br /> <br /> Entonces la segunda regla no necesita revalidar j2, y, por extensión j3,<br /> porque esto ya fue verificado durante la validación de la primera regla.<br /> Necesitamos validarlo solo para la regla 3.<br /> <br /> Esto es necesario porque la detección de bucles de cadena también asegura que no excedamos<br /> la pila de saltos: Solo porque sabemos que j2 está libre de ciclos, su último salto<br /> podría ahora exceder el tamaño de pila permitido. También necesitamos actualizar todas<br /> las cadenas alcanzables con la nueva profundidad de llamada más grande observada.<br /> <br /> Se debe tener cuidado de revalidar incluso si la profundidad de la cadena no será un<br /> problema: la validación de la cadena también asegura que las expresiones no se llamen desde<br /> cadenas base inválidas. Por ejemplo, la expresión de enmascaramiento solo puede ser<br /> llamada desde cadenas base de postrouting NAT.<br /> <br /> Por lo tanto, también necesitamos mantener un registro del contexto de la cadena base (tipo,<br /> hooknum) y revalidar si la cadena se vuelve alcanzable desde una ubicación de hook diferente.

Desreferencia de puntero nulo en free5gc pcf 1.4.0 en el archivo internal/sbi/processor/ampolicy.go en la función HandleDeletePoliciesPolAssoId.