Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: fix 6 GHz scan construction Si existen más de 255 APs coubicados para el conjunto de todos los APs encontrados durante el escaneo de 2.4/5 GHz, entonces la construcción del escaneo de 6 GHz se repetirá eternamente ya que la variable de bucle tiene tipo u8, que nunca puede alcanzar el número encontrado cuando es mayor a 255, y se almacena en una variable u32. También muévalo a los bucles para tener un alcance menor. Usar un u32 está bien, limitamos el número de APs en la lista de escaneo y cada uno tiene un límite en el número de entradas RNR debido al tamaño del marco. Con un límite de 1000 resultados de escaneo, un límite superior de tamaño de marco de 4096 (realmente es más como ~2300) y un tamaño de entrada TBTT de al menos 11, obtenemos un límite superior para el número de ~372k, bien en los límites de un u32.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: TSO: Fix DMA map/unmap no balanceado para datos SKB no paginados En caso de que los datos no paginados de un SKB lleven encabezado de protocolo y payload de protocolo para ser transmitidos en una determinada plataforma que el ancho de dirección DMA AXI está configurado a 40 bits/48 bits, o el tamaño de los datos no paginados es mayor que TSO_MAX_BUFF_SIZE en una determinada plataforma que el ancho de dirección DMA AXI está configurado a 32 bits, entonces este SKB requiere al menos dos descriptores de transmisión DMA para servirlo. Por ejemplo, se asignan tres descriptores para dividir un buffer DMA mapeado a partir de una pieza de datos no paginados: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Luego, se asignarán tres elementos de tx_q->tx_skbuff_dma[] para almacenar información adicional que se reutilizará en stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Ahora nos centramos en tx_q->tx_skbuff_dma[entry].buf, que es la dirección del búfer DMA devuelta por la llamada de mapeo DMA. stmmac_tx_clean() intentará desasignar el búfer DMA _SOLO_SI_ tx_q->tx_skbuff_dma[entry].buf es una dirección de búfer válida. El comportamiento esperado que guarda la dirección del buffer DMA de estos datos no paginados en tx_q->tx_skbuff_dma[entrada].buf es: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Desafortunadamente, el código actual se comporta mal de esta manera: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; En el lado stmmac_tx_clean(), cuando el motor DMA cierra dma_desc[N + 0], tx_q->tx_skbuff_dma[N + 0].buf es obviamente una dirección de búfer válida, entonces el búfer DMA se desasignará inmediatamente. Puede haber un caso poco común en el que el motor DMA no finalice aún los dma_desc[N + 1], dma_desc[N + 2] pendientes. Ahora las cosas saldrán terriblemente mal, DMA accederá a una región de memoria no mapeada/no referenciada, se transmitirán datos corruptos o se activará un error de iommu :( Por el contrario, el bucle for que mapea fragmentos SKB se comporta perfectamente como se espera, y así es como el controlador debería funcionar tanto para datos no paginados como para fragmentos paginados en realidad. Este parche corrige las secuencias de mapeo/desasignamiento de DMA al arreglar el índice de matriz para tx_q->tx_skbuff_dma[entry].buf al asignar la dirección del búfer de DMA. Probado y verificado en DWXGMAC CORE 3.20a

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: evitar la desreferenciación de punteros NULL si no se admite ATIF acpi_evaluate_object() puede devolver AE_NOT_FOUND (error), lo que provocaría la desreferenciación de buffer.pointer (obj) mientras sea NULL. Aunque este caso puede ser poco realista para el código actual, sigue siendo mejor protegerse contra posibles errores. También se debe abandonar cuando el estado sea AE_NOT_FOUND. Esto soluciona 1 problema de FORWARD_NULL informado por Coverity Report: CID 1600951: Desreferencias de punteros nulos (FORWARD_NULL) (seleccionado de el commit 91c9e221fe2553edf2db71627d8453f083de87a1)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: s5p-jpeg: evitar desbordamientos de búfer La lógica actual permite que word sea menor que 2. Si esto sucede, habrá desbordamientos de búfer, como lo informa smatch. Agregue verificaciones adicionales para evitarlo. Mientras esté aquí, elimine una asignación word = 0 sin usar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: stop qdisc_tree_reduce_backlog en TC_H_ROOT En qdisc_tree_reduce_backlog, se supone que las Qdisc con el identificador principal ffff: son raíz o de entrada. Esta suposición es falsa ya que es válido crear qdiscs de salida con el identificador principal ffff: Budimir Markovic descubrió que para las qdisc como DRR que mantienen una lista de clases activa, provocará un UAF con un puntero de clase colgante. En 066a3b5b2346, la preocupación era evitar iterar sobre la qdisc de entrada ya que su padre es ella misma. La solución adecuada es detener cuando se alcanza el padre TC_H_ROOT porque la única forma de recuperar la entrada es cuando una jerarquía que no contiene un identificador principal ffff: llama a qdisc_lookup con TC_H_MAJ(TC_H_ROOT). En el escenario donde el ffff principal es una qdisc de salida en cualquiera de los niveles del árbol, las actualizaciones también se propagarán a TC_H_ROOT, donde luego la iteración debe detenerse. net/sched/sch_api.c | 2 +- 1 archivo modificado, 1 inserción(+), 1 eliminación(-)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: Se ha corregido el manejo de respuestas en iwl_mvm_send_recovery_cmd() 1. No se valida el tamaño del paquete de respuesta. 2. No se libera el búfer de respuesta. Resuelva estos problemas cambiando a iwl_mvm_send_cmd_status(), que maneja tanto la validación del tamaño como la liberación del búfer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_api: corregir la ruta del error xa_insert() en tcf_block_get_ext() Este comando: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: la inserción dev del bloque falló: -EBUSY. falla porque el espacio de usuario solicita que se configure el mismo índice de bloque tanto para el ingreso como para el egreso. [nota al margen, no creo que haya fallado antes del commit 913b47d3424e ("net/sched: Introduce tc block netdev tracking infra"), porque este es un comando de un antiguo conjunto de notas mías que solían funcionar, pero por desgracia, no lo dividí científicamente] El problema no es que falle, sino que la segunda vez, falla de forma diferente (e irrecuperable): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [otra nota: el extack lo agregué yo con fines ilustrativos. El contexto del problema es que clsact_init() obtiene el mismo puntero &q->ingress_block que &q->egress_block, y dado que llamamos a tcf_block_get_ext() en ambos, "dev" se agregará al xarray block->ports dos veces, lo que hará que la operación falle: una vez a través del puntero del bloque de ingreso y otra vez a través del puntero del bloque de egreso. El problema en sí es que cuando xa_insert() falla, hemos emitido un comando FLOW_BLOCK_BIND a través de ndo_setup_tc(), pero la descarga nunca ve un FLOW_BLOCK_UNBIND correspondiente. Incluso corrigiendo la entrada incorrecta del usuario, aún no podemos recuperarnos: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: el bloque de flujo cb está ocupado. Básicamente, la única forma de recuperarse es reiniciar el sistema o desvincular y volver a vincular el controlador del dispositivo de red. Para corregir el error, debemos completar la ruta de desmontaje de error correcta que se omitió durante el movimiento del código y llamar a tcf_block_offload_unbind() cuando falla xa_insert(). [Última nota: fundamentalmente culpo a la convención de nombres de etiquetas en tcf_block_get_ext() por el error. Las etiquetas deben tener el nombre de lo que hacen, no de la ruta de error que las lleva a ellas. De esta manera, es obviamente incorrecto que dos etiquetas que apuntan al mismo código signifiquen que algo está mal, y verificar la corrección del código en el sitio de destino también es más fácil]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: dapm: corrección de error del verificador de los límites en dapm_widget_list_create La matriz de widgets en snd_soc_dapm_widget_list tiene un atributo __counted_by adjunto, que apunta a la variable num_widgets. Este atributo se utiliza en la comprobación de los límites y, si no se configura antes de que se llene la matriz, el sanitizador de los límites emitirá una advertencia o un pánico del kernel si se configura CONFIG_UBSAN_TRAP. Este parche establece el tamaño de la lista de widgets calculada con list_for_each como el valor inicial para num_widgets, ya que se utiliza para asignar memoria para la matriz. Se actualiza con el número real de elementos agregados después de que se llena la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: dts: imx8ulp: corrija la cadena compatible con flexspi El flexspi en imx8ulp solo tiene 16 LUT, y el flexspi de imx8mm tiene 32 LUT, así que corrija la cadena compatible aquí, de lo contrario se encontrará con el siguiente error: [ 1.119072] ------------[ cortar aquí ]------------ [ 1.123926] ADVERTENCIA: CPU: 0 PID: 1 en drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Módulos vinculados en: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Nombre del hardware: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: 0 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 00000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 00000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 00000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 000000000000007a6 [ 1.238795] x2 : 000000000000000 x1 : 00000000000001ce x0 : 000000000ffffff92 [ 1.246267] Rastreo de llamadas: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] de_registro_dispositivo_spi+0x3b4/0x590 [ 1.322348] controlador_registro_spi+0x47c/0x754 [ 1.327181] controlador_registro_spi_devm+0x4c/0xa4 [ 1.332289] sonda_nxp_fspi+0x1cc/0x2b0 [ 1.336307] sonda_plataforma+0x68/0xc4 [ 1.340145] sonda_realmente+0xbc/0x29c [ 1.343893] dispositivo_sonda_controlador+0x78/0x12c [ 1.348457] dispositivo_sonda_controlador+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_para_cada_dispositivo+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] hacer_una_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ fin del seguimiento 000000000000000 ]--- [ 1.407908] ------------[ cortar aquí ]------------

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp i2c: maneja dirección de encabezado NULL. daddr puede ser NULL si no hay ninguna entrada presente en la tabla de vecinos, en ese caso el paquete tx debe descartarse. saddr generalmente será configurado por el núcleo MCTP, pero verifica si es NULL en caso de que un paquete sea transmitido por un protocolo diferente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: ip_tunnel: Se corrige la advertencia de uso sospechoso de RCU en ip_tunnel_init_flow() Hay rutas de código desde las que se llama a la función sin mantener el bloqueo de lectura de RCU, lo que resulta en una advertencia de uso sospechoso de RCU [1]. Se soluciona utilizando l3mdev_master_upper_ifindex_by_index() que adquirirá el bloqueo de lectura de RCU antes de llamar a l3mdev_master_upper_ifindex_by_index_rcu(). [1] ADVERTENCIA: uso sospechoso de RCU 6.12.0-rc3-custom-gac8f72681cf2 #141 No contaminado ----------------------------- net/core/dev.c:876 ¡Lista de RCU recorrida en una sección que no es de lectura! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo retenido por ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, en: rtnetlink_rcv_msg+0x377/0xf60 seguimiento de pila: CPU: 3 UID: 0 PID: 361 Comm: ip No contaminado 6.12.0-rc3-custom-gac8f72681cf2 #141 Nombre del hardware: Bochs Bochs, BIOS Bochs 01/01/2011 Seguimiento de llamadas: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 enlace de túnel ip_dev+0x72f/0xa00 nuevo enlace ip_tunnel+0x368/0x7a0 nuevo enlace ipgre+0x14c/0x170 nuevo enlace __rtnl+0x1173/0x19c0 nuevo enlace rtnl+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 unidifusión netlink+0x539/0x7f0 envío netlink_msg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 hacer_syscall_64+0xbb/0x1d0 entrada_SYSCALL_64_después_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: resource,kexec: walk_system_ram_res_rev debe conservar los indicadores de recursos walk_system_ram_res_rev() descarta erróneamente los indicadores de recursos al pasar la información a la devolución de llamada. Esto hace que los sistemas con memoria IORESOURCE_SYSRAM_DRIVER_MANAGED tengan estos recursos seleccionados durante kexec para almacenar búferes kexec si esa memoria está ubicada por encima de la RAM normal del sistema. Esto conduce a un comportamiento indefinido después del reinicio. Si nunca se toca el búfer kexec, no sucede nada. Si se toca el búfer kexec, podría provocar un bloqueo (como a continuación) o un comportamiento indefinido. Probado en un sistema con expansores de memoria CXL con memoria administrada por el controlador, TPM habilitado y CONFIG_IMA_KEXEC=y. Agregar printk mostró que los indicadores se descartaban y, como resultado, la verificación de IORESOURCE_SYSRAM_DRIVER_MANAGED pasa. find_next_iomem_res: name(System RAM (kmem)) start(10000000000) end(1034fffffff) flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] ERROR: no se puede manejar el error de página para la dirección: ffff89834ffff000 [.] #PF: acceso de lectura del supervisor en modo kernel [.] #PF: error_code(0x0000) - página no presente [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:lista_de_mediciones_de_restauración_ima+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: enlace SATA inactivo (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Seguimiento de llamadas: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? plantilla_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] hacer_una_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? nueva_losa+0x12c/0x420 [.] ? nueva_losa+0x12c/0x420 [.] ? numero+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? analizar_args+0xd4/0x380 [.] ? analizar_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_desde_fork_asm+0x11/0x20 [.]