Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/netfront: fortalece netfront contra tormentas de canales de eventos El controlador Xen netfront aún es vulnerable a un ataque mediante un número excesivo de eventos enviados por el backend. Solucione eso usando canales de eventos de lateeoi. Para poder detectar el caso de que no se agreguen respuestas rx mientras el operador está inactivo, se necesita un nuevo bloqueo para actualizar y probar rsp_cons y la cantidad de respuestas no consumidas vistas de forma atómica. Esto es parte de XSA-391 --- V2: - no haga eoi irq en caso de que la interfaz esté rota (Jan Beulich) - maneje el operador apagado + no se agregaron nuevas respuestas (Jan Beulich) V3: - agregue el prefijo rx_ a rsp_unconsumed ( Jan Beulich) - ortografía correcta de xennet_set_rx_rsp_cons() (Jan Beulich)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: m68k: corrige la ejecución de bloqueo de giro en la creación de subprocesos del kernel. El cambio de contexto se encarga de retener el propietario del bloqueo correcto durante el cambio de las tareas 'anteriores' a las 'siguientes'. Esto depende de que las interrupciones permanezcan deshabilitadas durante toda la duración del cambio. Esta condición está garantizada para la creación normal de procesos y el cambio de contexto entre procesos que ya se están ejecutando, porque tanto 'anterior' como 'siguiente' ya tienen las interrupciones deshabilitadas en sus copias guardadas del registro de estado. La situación es diferente para los subprocesos del kernel recién creados. El registro de estado se establece en PS_S en copy_thread(), lo que deja la IPL en 0. Al restaurar el registro de estado del 'siguiente' subproceso en switch_to() también conocido como resume(), las interrupciones se habilitan prematuramente. resume() luego regresa a través de ret_from_kernel_thread() y Schedule_tail() donde se libera el bloqueo de la cola de ejecución (consulte Finish_task_switch() y Finish_lock_switch()). Una interrupción del temporizador que llama a Scheduler_tick() antes de que se libere el bloqueo en Finish_task_switch() encontrará el bloqueo ya tomado, con la tarea actual como propietario del bloqueo. Esto provoca una advertencia de recursividad de spinlock según lo informado por Guenter Roeck. Hasta donde puedo determinar, esta ejecución se abrió en el commit 533e6903bea0 ("m68k: split ret_from_fork(), simplifica kernel_thread()") pero no he realizado un estudio detallado de la historia del kernel, por lo que es posible que sea anterior a esa confirmación. Las interrupciones no se pueden deshabilitar en la copia del registro de estado guardado para los subprocesos del kernel (init se quejará de las interrupciones deshabilitadas cuando finalmente inicie el espacio de usuario). Deshabilite las interrupciones temporalmente al cambiar los conjuntos de registros de tareas en resume(). Tenga en cuenta que un simple oriw 0x700,%sr después de restaurar sr no es suficiente aquí; esto deja suficiente ejecución para que aún se observe la advertencia de 'recursión de spinlock'. Probado en ARAnyM y qemu (emulación Quadra 800).

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: openrisc: trampas: no envía señales a subprocesos en modo kernel. El manejo de excepciones de OpenRISC envía señales a los procesos del usuario sobre excepciones de punto flotante e instrucciones de captura (para depuración), entre otros. Hay un error en el que la lógica de manejo de trampas puede enviar señales a los subprocesos del kernel. No debemos enviar estas señales a los subprocesos del kernel; si eso sucede, lo tratamos como un error. Este parche agrega condiciones para morir si el kernel recibe estas excepciones en el código del modo kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: la devolución de llamada exit() es opcional La devolución de llamada exit() es opcional y no debe llamarse sin verificar primero un puntero válido. Además, debemos borrar el puntero freq_table incluso si la devolución de llamada exit() no está presente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: carl9170: volver a corregir la advertencia de memset fortificado La función carl9170_tx_release() a veces activa una advertencia de memset fortificado en mis compilaciones de randconfig: en el archivo incluido en include/linux/string. h:254, de drivers/net/wireless/ath/carl9170/tx.c:40: en la función 'fortify_memset_chk', insertado desde 'carl9170_tx_release' en drivers/net/wireless/ath/carl9170/tx.c:283:2 , incluido desde 'kref_put' en include/linux/kref.h:65:3, incluido desde 'carl9170_tx_put_skb' en drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string .h:493:25: error: llamada a '__write_overflow_field' declarada con advertencia de atributo: escritura detectada más allá del tamaño del campo (primer parámetro); ¿Quizás usar struct_group()? [-Werror=advertencia-atributo] 493 | __write_overflow_field(p_size_field, tamaño); Kees anteriormente intentó evitar esto usando memset_after(), pero parece que esto no soluciona completamente el problema. Me di cuenta de que memset_after() aquí se realiza en una parte diferente de la unión (estado) de la que provenía la conversión original (rate_driver_data), lo que puede confundir al compilador. Desafortunadamente, el truco memset_after() no funciona en driver_rates[] porque es parte de una estructura anónima y tampoco pude lograr que struct_group() hiciera esto. Sin embargo, el uso de dos llamadas memset() separadas en los dos miembros soluciona la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kunit/fortify: corrige el uso no coincidente de kvalloc()/vfree() La familia de pruebas kv*() se liberaba accidentalmente con vfree() en lugar de kvfree(). Utilice kvfree() en su lugar.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: sr: corrige la ruta de error de cancelación de registro no válida La ruta de error de seg6_init() es incorrecta en caso de que CONFIG_IPV6_SEG6_LWTUNNEL no esté definido. En ese caso, si seg6_hmac_init() falla, no se llama a genl_unregister_family(). Este problema existe desde que el commit 46738b1317e1 ("ipv6: sr: agregar opción para controlar la compatibilidad con lwtunnel") y el commit 5559cea2d5aa ("ipv6: sr: corregir posible use-after-free y null-ptr-deref") reemplazó unregister_pernet_subsys() con genl_unregister_family() en esta ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: temporizador: establece el límite inferior del tiempo de inicio. Actualmente, el temporizador ALSA no tiene el límite inferior del tiempo de inicio y permite un tamaño muy pequeño, por ejemplo, 1 tic. con resolución de 1ns para hrtimer. Tal situación puede provocar una parada inesperada de la RCU, donde la devolución de llamada pone en cola repetidamente la actualización caducada, según lo informado por fuzzer. Este parche introduce una verificación de cordura del tiempo de inicio del temporizador, de modo que el sistema devuelve un error cuando se establece un tamaño de inicio demasiado pequeño. A partir de este parche, el límite inferior está codificado en 100us, que es bastante pequeño pero aún puede funcionar de alguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ax25: soluciona problemas de pérdida de recuento de referencias de ax25_dev. Ax25_addr_ax25dev() y ax25_dev_device_down() existen un problema de pérdida de recuento de referencias del objeto "ax25_dev". Problema de pérdida de memoria en ax25_addr_ax25dev(): el recuento de referencias del objeto "ax25_dev" se puede aumentar varias veces en ax25_addr_ax25dev(). Esto provocará una pérdida de memoria. Problemas de pérdida de memoria en ax25_dev_device_down(): el recuento de referencias de ax25_dev se establece en 1 en ax25_dev_device_up() y luego aumenta el recuento de referencias cuando se agrega ax25_dev a ax25_dev_list. Como resultado, el recuento de referencia de ax25_dev es 2. Pero cuando el dispositivo se está apagando. El ax25_dev_device_down() reduce el recuento de referencias una o dos veces dependiendo de si vamos a unlock_put o no, lo que provocará una pérdida de memoria. En cuanto al problema de ax25_addr_ax25dev(), es imposible que un puntero esté en una lista dos veces. Entonces agregue una interrupción en ax25_addr_ax25dev(). En cuanto al problema de ax25_dev_device_down(), aumente el recuento de referencias de ax25_dev una vez en ax25_dev_device_up() y disminuya el recuento de referencias de ax25_dev después de que se elimine de ax25_dev_list.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers/perf: hisi: hns3: en realidad usa devm_add_action_or_reset() pci_alloc_irq_vectors() asigna un vector irq. Cuando devm_add_action() falla, el vector irq no se libera, lo que provoca una pérdida de memoria. Reemplace devm_add_action con devm_add_action_or_reset para garantizar que el vector irq pueda destruirse cuando falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: refina la comprobación de EOF en blkdev_iomap_begin blkdev_iomap_begin redondea hacia abajo el desplazamiento al tamaño del bloque lógico antes de guardarlo en iomap->offset y comprobar que todavía está dentro del tamaño del inodo. Verifique la verificación i_size en el valor pos sin formato para que no intentemos una escritura de tamaño cero si iter->pos no está alineado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: núcleo: corrige la asignación del puntero del módulo NULL en el inicio de la tarjeta el commit 81033c6b584b ("ALSA: núcleo: Advertencia sobre módulo vacío") introdujo un WARN_ON() para un puntero de módulo NULL pasado en la creación del objeto snd_card, y también envuelve el código a su alrededor con '#ifdef MODULE'. Esto funciona en la mayoría de los casos, pero los problemas siempre están en los detalles. "MÓDULO" se define cuando el código objetivo (es decir, el núcleo de sonido) se construye como un módulo; pero esto no significa que la persona que llama también esté integrada o no. Es decir, cuando solo el núcleo de sonido está integrado (CONFIG_SND=y) mientras el controlador es un módulo (CONFIG_SND_USB_AUDIO=m), el puntero del módulo pasado se ignora incluso si no es NULL, y tarjeta->módulo permanece como NULL. Esto daría como resultado que la referencia del módulo faltante suba o baje en la apertura o cierre del dispositivo, lo que provocaría una ejecución con la ejecución del código después de la eliminación del módulo. Para solucionar el error, mueva la asignación de tarjeta->módulo nuevamente fuera de ifdef. WARN_ON() todavía está incluido en ifdef porque el módulo puede ser realmente NULL cuando todos los controladores de sonido están integrados. Tenga en cuenta que mantenemos 'ifdef MODULE' para WARN_ON(); de lo contrario, se produciría una verificación de módulo NULL falsamente positiva. Es cierto que no se detectará perfectamente, es decir, no se realiza ninguna verificación cuando CONFIG_SND=y. Pero no es un problema real ya que es solo para depurar y la condición es bastante rara.