Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gso: arregla la segmentación de tcp fraglist después de extraer de frag_list Detecta skbs tcp gso fraglist con geometría corrupta (ver abajo) y pásalos a skb_segment en lugar de a skb_segment_list, ya que el primero puede segmentarlos correctamente. Skbs SKB_GSO_FRAGLIST válidos: consisten en dos o más segmentos: el head_skb contiene los encabezados de protocolo más el primer gso_size: uno o más skbs frag_list contienen exactamente un segmento: todos menos el último deben ser gso_size Los ganchos de ruta de datos opcionales como NAT y BPF (bpf_skb_pull_data) pueden modificar estos skbs, rompiendo estos invariantes. En casos extremos, extraen todos los datos en skb lineal. Para TCP, esto provoca un desreferenciado de ptr NULL en __tcpv4_gso_segment_list_csum en tcp_hdr(seg->next). Detecta geometría no válida debido a la extracción, verificando el tamaño de head_skb. No lo descartes, ya que esto puede convertir un destino en un agujero negro. Convierte para poder pasar a skb_segment normal. Enfoque y descripción basados en un parche de Willem de Bruijn.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: se corrige la fuga de free_huge_pages de memfd_pin_folios memfd_pin_folios seguido de unpin_folios no puede restaurar free_huge_pages si las páginas no tenían ya un error, porque el recuento de referencias de folio para las páginas creadas por memfd_alloc_folio nunca llega a 0. memfd_pin_folios necesita otro folio_put para deshacer el folio_try_get a continuación: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; agrega 1 recuento de referencias folio_try_get() ; agrega 1 recuento de referencias hugetlb_add_to_page_cache() ; agrega 512 refcount (en x86) Con la solución, después de memfd_pin_folios + unpin_folios, el refcount para la página (sin fallos) es 512, lo cual es correcto, ya que el refcount para una página sin fijar con fallos es 513.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: no es necesario continuar cuando el número de entradas es 1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Implementar comprobación de los límites para la creación de codificadores de flujo en DCN401 La matriz 'stream_enc_regs' es una matriz de estructuras dcn10_stream_enc_registers. La matriz se inicializa con cuatro elementos, que corresponden a las cuatro llamadas a stream_enc_regs() en el inicializador de la matriz. Esto significa que los índices válidos para esta matriz son 0, 1, 2 y 3. El mensaje de error 'stream_enc_regs' 4 <= 5 a continuación indica que hay un intento de acceder a esta matriz con un índice de 5, que está fuera de los límites. Esto podría provocar un comportamiento indefinido Aquí, eng_id se utiliza como índice para acceder a la matriz stream_enc_regs. Si eng_id es 5, esto daría como resultado un acceso fuera de los límites en la matriz stream_enc_regs. De esta forma se soluciona el error de desbordamiento de búfer en dcn401_stream_encoder_create. Encontrado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 Error en dcn401_stream_encoder_create(): desbordamiento de búfer 'stream_enc_regs' 4 <= 5

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: los sistemas de archivos sin la función casefold no se pueden montar con siphash Al montar el sistema de archivos ext4, si la versión hash predeterminada está configurada en DX_HASH_SIPHASH pero la función casefold no está configurada, salga del montaje.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: reserva espacio para xattr en línea antes de adjuntar árbol reflink Uno de nuestros clientes informó de un fallo y un sistema de archivos ocfs2 dañado. El fallo se debió a la detección de una corrupción. Tras la resolución de problemas, la salida de fsck -fn mostró la siguiente corrupción [EXTENT_LIST_FREE] La lista de extensiones del propietario 33080590 afirma que 230 es el siguiente registro de cadena libre, pero fsck cree que el valor válido más grande es 227. ¿Fijar el siguiente valor de registro? n La salida de estadísticas de debugfs.ocfs2 mostró la siguiente corrupción, donde "Next Free Rec:" había superado "Count:" en el bloque de metadatos raíz. Inodo: 33080590 Modo: 0640 Generación: 2619713622 (0x9c25a856) Generación FS: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Tipo: Regular Atributo: 0x0 Indicadores: Válido Características dinámicas: (0x16) HasXattr InlineXattr Refcounted Bloque de atributos extendidos: 0 Tamaño en línea de atributos extendidos: 256 Usuario: 0 (raíz) Grupo: 0 (raíz) Tamaño: 281320357888 Enlaces: 1 Clústeres: 141738 ctime: 0x66911b56 0x316edcb8 -- Vie Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Vie Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Vie Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Mié Dic 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... ....... ....... El problema estaba en el flujo de trabajo de reflink mientras se reservaba espacio para xattr en línea. La función problemática es ocfs2_reflink_xattr_inline(). Para cuando se llama a esta función, el árbol de reflink ya se ha recreado en el inodo de destino a partir del inodo de origen. En este punto, esta función reserva espacio para xattrs en línea en el inodo de destino sin siquiera verificar si hay espacio en el bloque de metadatos raíz. Simplemente reduce el l_count de 243 a 227, lo que crea un espacio de 256 bytes para xattr en línea, mientras que el inodo ya tiene extensiones más allá de este índice (en este caso, hasta 230), lo que provoca corrupción. La solución para esto es reservar espacio para metadatos en línea en el inodo de destino antes de que se vuelva a crear el árbol de enlaces de referencia. El cliente ha verificado la solución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jbd2: dejad de esperar espacio cuando jbd2_cleanup_journal_tail() devuelve un error En __jbd2_log_wait_for_space(), podríamos llamar a jbd2_cleanup_journal_tail() para recuperar algo de espacio en el diario. Pero si ocurre un error mientras se ejecuta jbd2_cleanup_journal_tail() (por ejemplo, un EIO), no dejamos de esperar espacio libre de inmediato, probamos otras ramas y, si j_committing_transaction es NULL (es decir, el tid es 0), obtendremos la siguiente queja: =============================================== JBD2: Error de E/S al actualizar el superbloque del diario para sdd-8. __jbd2_log_wait_for_space: se necesitaban 256 bloques y solo había 217 de espacio disponible __jbd2_log_wait_for_space: no hay forma de obtener más espacio de diario en sdd-8 ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 139804 en fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Módulos vinculados: CPU: 2 PID: 139804 Comm: kworker/u8:3 No contaminado 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Rastreo de llamadas: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] == ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: fix timer use-after-free on failed mount Syzbot ha encontrado un error ODEBUG en ext4_fill_super La función del_timer_sync cancela el temporizador s_err_report, que recuerda los errores del sistema de archivos a diario. Debemos garantizar que el temporizador ya no esté activo antes de kfree(sbi). Cuando falla el montaje del sistema de archivos, el flujo va a failed_mount3, donde ocurre un error cuando se llama a ext4_stop_mmpd, lo que causa un error de E/S de lectura. Esto activa la función ext4_handle_error que, en última instancia, vuelve a armar el temporizador, dejando el temporizador s_err_report activo antes de que se llame a kfree(sbi). Solucione el problema cancelando el temporizador s_err_report después de llamar a ext4_stop_mmpd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: i2c: ar0521: Usar la versión cansleep de gpiod_set_value() Si usamos el restablecimiento de GPIO desde el expansor de puerto I2C, debemos usar la variante *_cansleep() de las funciones GPIO. Esto no se hacía en las funciones ar0521_power_on()/ar0521_power_off(). Vamos a solucionarlo. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 11 en drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Módulos vinculados en: CPU: 0 PID: 11 Comm: kworker/u16:0 No contaminado 6.10.0 #53 Nombre del hardware: Diasom DS-RK3568-SOM-EVB (DT) Cola de trabajo: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9: ffffff8001d7a9f0 x8: ffffff8001d92570 x7: ffffff80efeeac80 x6: 000000003fc6e780 x5: ffffff8001d91c80 x4: 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Rastreo de llamadas: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: comprobar el retorno nulo de ACPI_ALLOCATE_ZEROED() en acpi_db_convert_to_package() Confirmación de ACPICA 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() puede fallar, los elementos pueden ser NULL y causarán una desreferencia de puntero NULL más adelante. [ rjw: Ediciones de asunto y registro de cambios ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mailbox: bcm2835: Fix timeout during suspend mode Durante la fase de suspensión de noirq, el controlador de energía de Raspberry Pi sufre tiempos de espera de propiedad de firmware. La razón es que la IRQ del buzón BCM2835 subyacente está deshabilitada y rpi_firmware_property_list() siempre se encontrará con un tiempo de espera [1]. Dado que el lado de VideoCore no se considera una fuente de reactivación, configure el indicador IRQF_NO_SUSPEND para el IRQ del buzón para mantenerlo habilitado durante el ciclo de suspensión-reanudación. [1] PM: suspensión tardía de dispositivos completada después de 1,754 msegs ADVERTENCIA: CPU: 0 PID: 438 en drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Tiempo de espera de transacción de firmware 0x00028001 Módulos vinculados: CPU: 0 PID: 438 Comm: bash Tainted: GC 6.9.3-dirty #17 Nombre del hardware: BCM2835 Rastreo de llamadas: unwind_backtrace de show_stack+0x18/0x1c show_stack de dump_stack_lvl+0x34/0x44 dump_stack_lvl de __warn+0x88/0xec __warn de warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt de rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list de rpi_firmware_property+0x68/0x8c rpi_firmware_property de rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power de _genpd_power_off+0xe4/0x148 _genpd_power_off de genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off de genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend de dpm_run_callback+0x78/0xd0 dpm_run_callback de device_suspend_noirq+0xc0/0x238 device_suspend_noirq de dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq desde suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter desde pm_suspend+0x254/0x2e4 pm_suspend desde state_store+0xa8/0xd4 state_store desde kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter desde vfs_write+0x12c/0x184 vfs_write desde ksys_write+0x78/0xc0 ksys_write desde ret_fast_syscall+0x0/0x54 Pila de excepciones (0xcc93dfa8 a 0xcc93dff0) [...] PM: suspensión noirq de dispositivos completada después de 3095,584 mseg

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: eliminar el desbloqueo irrazonable en ocfs2_read_blocks Serie de parches "Correcciones varias para ocfs2_read_blocks", v5. Esta serie contiene 2 correcciones para ocfs2_read_blocks(). El primer parche corrige el problema informado por syzbot, que detecta un balance de desbloqueo incorrecto en ocfs2_read_blocks(). El segundo parche corrige un problema informado por Heming Zhao al revisar la corrección anterior. Este parche (de 2): Hubo una liberación de bloqueo antes de salir, así que elimine el desbloqueo irrazonable.