Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvme-fc: liberar el conjunto de etiquetas de administración si la inicialización falla<br /> <br /> nvme_fabrics crea un controlador NVMe/FC en la siguiente ruta:<br /> <br /> nvmf_dev_write()<br /> -&amp;gt; nvmf_create_ctrl()<br /> -&amp;gt; nvme_fc_create_ctrl()<br /> -&amp;gt; nvme_fc_init_ctrl()<br /> <br /> nvme_fc_init_ctrl() asigna los recursos blk-mq de administración justo después de que nvme_add_ctrl() tenga éxito. Si alguno de los pasos subsiguientes falla (cambiar el estado del controlador, programar el trabajo de conexión, etc.), saltamos a la ruta fail_ctrl, que desmantela las referencias del controlador pero nunca libera la cola/conjunto de etiquetas de administración. Las asignaciones blk-mq filtradas coinciden con el informe kmemleak visto durante blktests nvme/fc.<br /> <br /> Verificar ctrl-&amp;gt;ctrl.admin_tagset en la ruta fail_ctrl y llamar a nvme_remove_admin_tag_set() cuando esté establecido para que todas las asignaciones de la cola de administración sean recuperadas cada vez que la configuración del controlador se aborte.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gve: Corrección de la corrupción del informe de estadísticas al cambiar el recuento de colas<br /> <br /> El controlador y la NIC comparten una región en memoria para el informe de estadísticas.<br /> La NIC calcula su desplazamiento en esta región basándose en el tamaño total<br /> de la región de estadísticas y el tamaño de las estadísticas de la NIC.<br /> <br /> Cuando se cambia el número de colas, la región de estadísticas del controlador se<br /> redimensiona. Si el recuento de colas se incrementa, la NIC puede escribir más allá<br /> del final de la región de estadísticas asignada, causando corrupción de memoria.<br /> Si el recuento de colas se disminuye, hay una brecha entre las estadísticas del controlador<br /> y de la NIC, lo que lleva a un informe de estadísticas incorrecto.<br /> <br /> Este cambio soluciona el problema asignando la región de estadísticas con el tamaño<br /> máximo, y el cálculo del desplazamiento para las estadísticas de la NIC se cambia para que<br /> coincida con el cálculo de la NIC.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> io_uring/zcrx: corregir fuga de array de páginas<br /> <br /> d9f595b9a65e (&amp;#39;io_uring/zcrx: corregir la fuga de páginas al fallar la inicialización de sg&amp;#39;) corrigió una fuga de páginas pero no liberó el array de páginas, libéralo también.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> xfs: solo llamar a xf{array,blob}_destroy si tenemos un puntero válido<br /> <br /> Solo llamar al destructor xfarray y xfblob si tenemos un puntero válido, y asegurarse de anular ese puntero después. Tenga en cuenta que este parche soluciona un gran número de commits, la mayoría de los cuales fueron fusionados entre 6.9 y 6.10.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: gro: corregir desplazamiento de red externo<br /> <br /> La etapa de completado de GRO de UDP asume que todos los paquetes insertados en el RX tienen el indicador &amp;#39;encapsulation&amp;#39; puesto a cero. Dicha suposición no es cierta, ya que algunas NIC de H/W pueden establecer dicho indicador al descargar el checksum por H/W para un tráfico UDP encapsulado, el controlador tun puede inyectar paquetes GSO con encapsulación UDP y la disposición problemática también puede crearse a través de una configuración basada en veth.<br /> <br /> Debido a lo anterior, en los escenarios problemáticos, udp4_gro_complete() utiliza el desplazamiento de red incorrecto (interno en lugar de externo) para calcular el pseudo checksum del encabezado UDP externo, lo que lleva a errores de validación de csum más adelante en el procesamiento de paquetes.<br /> <br /> Abordar el problema siempre borrando el indicador de encapsulación en el momento de completado de GRO. Dicho indicador se establecerá de nuevo según sea necesario para paquetes encapsulados por udp_gro_complete().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: liquidio: Corrección de error de uno en la limpieza de VF setup_nic_devices()<br /> <br /> En setup_nic_devices(), el bucle de inicialización salta a la etiqueta setup_nic_dev_free en caso de fallo. El bucle de limpieza actual while(i--) omite el índice i que falla, causando una fuga de memoria.<br /> <br /> Esto se corrige cambiando el bucle para que itere desde el índice actual i hasta 0.<br /> <br /> Solo probado en compilación. Problema encontrado mediante revisión de código.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: liquidio: Corrección de error &amp;#39;off-by-one&amp;#39; en la limpieza de PF setup_nic_devices()<br /> <br /> En setup_nic_devices(), el bucle de inicialización salta a la etiqueta setup_nic_dev_free en caso de fallo. El bucle de limpieza actual while(i--) omite el índice &amp;#39;i&amp;#39; fallido, causando una fuga de memoria.<br /> <br /> Esto se corrige cambiando el bucle para que itere desde el índice actual &amp;#39;i&amp;#39; hasta 0.<br /> <br /> Además, se decrementa &amp;#39;i&amp;#39; en la ruta de fallo de devlink_alloc para que apunte al último índice asignado con éxito.<br /> <br /> Probado solo en compilación. Problema encontrado mediante revisión de código.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> xfs: eliminar las llamadas a xchk_xfile_*_descr<br /> <br /> Las macros xchk_xfile_*_descr llaman a kasprintf, lo que puede fallar al asignar memoria si la cadena formateada es mayor de 16 bytes (o cualesquiera que sean las garantías de nofail hoy en día). Algunas de ellas podrían exceder fácilmente eso, y Jiaming Zhang encontró algunos lugares donde eso puede ocurrir con syzbot.<br /> <br /> Las descripciones son ayudas de depuración y no se requiere que sean únicas, así que simplemente pasemos cadenas estáticas y eliminemos esta ruta de fallo. Nótese que este parche afecta a varios commits, la mayoría de los cuales fueron fusionados entre 6.6 y 6.14.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: añadir protección RCU adecuada a /proc/net/ptype<br /> <br /> Yin Fengwei informó de un bloqueo RCU en ptype_seq_show() y proporcionó un parche.<br /> <br /> El problema real es que ptype_seq_next() y ptype_seq_show() violan las reglas RCU.<br /> <br /> ptype_seq_show() se ejecuta bajo rcu_read_lock(), y lee pt-&amp;gt;dev para obtener el nombre del dispositivo sin ninguna barrera.<br /> <br /> Al mismo tiempo, los escritores concurrentes pueden eliminar una estructura packet_type (que se libera correctamente después de un período de gracia RCU) y borrar pt-&amp;gt;dev sin un período de gracia RCU.<br /> <br /> Definir ptype_iter_state para llevar un puntero dev junto con seq_net_private:<br /> <br /> struct ptype_iter_state {<br /> struct seq_net_private p;<br /> struct net_device *dev; // añadido en este parche<br /> };<br /> <br /> Necesitamos registrar el puntero del dispositivo en ptype_get_idx() y ptype_seq_next() para que ptype_seq_show() esté a salvo de cambios concurrentes en pt-&amp;gt;dev.<br /> <br /> También necesitamos añadir protección RCU completa en ptype_seq_next().<br /> (Falta READ_ONCE() al leer los valores de list.next)<br /> <br /> Muchas gracias a Dong Chenchen por proporcionar una reproducción.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: dvb-core: corrige la reinicialización incorrecta del búfer circular al reabrir<br /> <br /> dvb_dvr_open() llama a dvb_ringbuffer_init() cuando un nuevo lector abre el dispositivo DVR. dvb_ringbuffer_init() llama a init_waitqueue_head(), lo que reinicializa la cabecera de la lista de la cola de espera a vacía.<br /> <br /> Dado que dmxdev-&amp;gt;dvr_buffer.queue es una cola de espera compartida (todas las aperturas del mismo dispositivo DVR la comparten), esto deja huérfanas las entradas existentes de la cola de espera de io_uring poll o epoll, dejándolas con punteros prev/next obsoletos mientras la cabecera de la lista se restablece a {self, self}.<br /> <br /> La cola de espera y el spinlock en dvr_buffer ya están correctamente inicializados una vez en dvb_dmxdev_init(). La ruta de apertura solo necesita restablecer el puntero de datos del búfer, el tamaño y las posiciones de lectura/escritura.<br /> <br /> Reemplace la llamada a dvb_ringbuffer_init() en dvb_dvr_open() con la asignación directa de datos/tamaño y una llamada a dvb_ringbuffer_reset(), que restablece correctamente pread, pwrite y error con el ordenamiento de memoria correcto sin tocar la cola de espera o el spinlock.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> LoongArch: Habilitar la corrección de excepciones para un subcódigo ADE específico<br /> <br /> Este parche permite al JIT BPF de LoongArch manejar errores de acceso a memoria recuperables generados por instrucciones BPF_PROBE_MEM*.<br /> <br /> Cuando un programa BPF realiza operaciones de acceso a memoria, las instrucciones que ejecuta pueden desencadenar excepciones ADEM. El mecanismo de tabla de excepciones BPF integrado del kernel (EX_TYPE_BPF) generará entradas de corrección de excepciones correspondientes en la fase de compilación JIT; sin embargo, la función de manejo de trampas específica de la arquitectura necesita llamar proactivamente a la rutina de corrección común para lograr la recuperación de la excepción.<br /> <br /> do_ade(): corrige las excepciones de acceso a memoria EX_TYPE_BPF para programas BPF, asegura la ejecución segura.<br /> <br /> Casos de prueba relevantes: pruebas de acceso a direcciones ilegales en module_attach y subprogs_extable de selftests/bpf.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> xfs: verificar cursores eliminados al revalidar dos btrees<br /> <br /> Las funciones de reparación de btree de espacio libre e inodo reconstruirán ambos btrees al mismo tiempo, después de lo cual necesita evaluar ambos btrees para confirmar que las corrupciones han desaparecido.<br /> <br /> Sin embargo, Jiaming Zhang ejecutó syzbot y produjo un fallo en la segunda llamada a xchk_allocbt. Su análisis de causa raíz es el siguiente (con correcciones menores):<br /> <br /> En xrep_revalidate_allocbt(), se llama a xchk_allocbt() dos veces (primero para BNOBT, segundo para CNTBT). La causa de este problema es que la primera llamada anuló el cursor requerido por la segunda llamada.<br /> <br /> Primero entremos en xrep_revalidate_allocbt() a través de la siguiente cadena de llamadas:<br /> <br /> xfs_file_ioctl() -&amp;gt;<br /> xfs_ioc_scrubv_metadata() -&amp;gt;<br /> xfs_scrub_metadata() -&amp;gt;<br /> &amp;#39;sc-&amp;gt;ops-&amp;gt;repair_eval(sc)&amp;#39; -&amp;gt;<br /> xrep_revalidate_allocbt()<br /> <br /> Se llama a xchk_allocbt() dos veces en esta función. En la primera llamada:<br /> <br /> /* Tenga en cuenta que sc-&amp;gt;sm-&amp;gt;sm_type es XFS_SCRUB_TYPE_BNOPT ahora */<br /> xchk_allocbt() -&amp;gt;<br /> xchk_btree() -&amp;gt;<br /> &amp;#39;bs-&amp;gt;scrub_rec(bs, recp)&amp;#39; -&amp;gt;<br /> xchk_allocbt_rec() -&amp;gt;<br /> xchk_allocbt_xref() -&amp;gt;<br /> xchk_allocbt_xref_other()<br /> <br /> dado que sm_type es XFS_SCRUB_TYPE_BNOBT, pur se establece en &amp;amp;sc-&amp;gt;sa.cnt_cur. El kernel llamó a xfs_alloc_get_rec() y devolvió -EFSCORRUPTED. Cadena de llamadas:<br /> <br /> xfs_alloc_get_rec() -&amp;gt;<br /> xfs_btree_get_rec() -&amp;gt;<br /> xfs_btree_check_block() -&amp;gt;<br /> (XFS_IS_CORRUPT || XFS_TEST_ERROR), el primero es falso y el segundo es verdadero, devuelve -EFSCORRUPTED. Esto debería ser causado por ioctl$XFS_IOC_ERROR_INJECTION, supongo.<br /> <br /> Volviendo a xchk_allocbt_xref_other(), después de recibir -EFSCORRUPTED de xfs_alloc_get_rec(), el kernel llamó a xchk_should_check_xref(). En esta función, *curpp (que apunta a sc-&amp;gt;sa.cnt_cur) es anulado.<br /> <br /> Volviendo a xrep_revalidate_allocbt(), dado que sc-&amp;gt;sa.cnt_cur ha sido anulado, entonces activó una desreferencia de puntero nulo a través de xchk_allocbt() (segunda llamada) -&amp;gt; xchk_btree().<br /> <br /> Así que. La revalidación de bnobt falló en un intento de referencia cruzada, por lo que eliminamos el cursor cntbt, y luego fallamos cuando intentamos revalidar el cntbt. Por lo tanto, verifique si hay un cursor cntbt nulo antes de esa revalidación, y marque la reparación como incompleta. También podemos ignorar el segundo árbol por completo si el primer árbol fue reconstruido pero ya está corrupto.<br /> <br /> Aplique la misma corrección a xrep_revalidate_iallocbt porque tiene el mismo problema.