Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: mcast: use la versión rcu-safe de ipv6_get_lladdr() Hace algún tiempo 8965779d2c0e ("ipv6,mcast: siempre mantenga presionado idev->lock antes de mca_lock") cambió ipv6_get_lladdr() a __ipv6_get_lladdr(), que es una versión insegura para rcu. Eso estuvo bien, porque se mantuvo idev->lock para estas rutas de código. En 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") se eliminaron estos bloqueos externos, por lo que probablemente necesitemos restaurar la llamada rcu-safe original. De lo contrario, ocasionalmente obtenemos una máquina que falla o se bloquea con lo siguiente en dmesg: [3405.966610][T230589] falla de protección general, probablemente para la dirección no canónica 0xdead00000000008c: 0000 [#1] SMP NOPTI [3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: GO 5.15.19-cloudflare-2022.2.1 #1 [ 3405.998061][T230589] Nombre de hardware: SUPA-COOL-SERV [ 3406.009552][T230589] Cola de trabajo: mld mld_ifc_work [ 3406 .017224 ][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60 [ 3406.025780][T230589] Código: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 <66> 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b [ 3406.055748][T230589] 0018:ffff94e4b3fc3d10 EFLAGS: 00010202 [ 3406.065617][T230589] RAX: muerto00000000005a RBX: ffff94e4b3fc3d30 RCX: 00000000000000040 [ 3406.077477][T230589] RDX: muerto0000000001 22 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008 [ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000000000 [ 34 06.101445][ T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100 [ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 0000000000 0005dc R15: ffff8c3a31431000 [ 3406.125730][T230589] FS: 0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000 [ 3406.1 38992] [T230589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0350ee0 [ 3406.162421][T230589] Seguimiento de llamadas: [ 3406.170235][T230589] [ 3406.177736 ] [T230589] Mld_newpack+0xfe/0x1a0 [3406.186686] [T230589] add_grhead+0x87/0xa0 [3406.195498] [T230589] add_grec+0x485/0x4e0 [3406.204310] newidle_balance+0x126/0x3f0 [ 3406.214024][T230589] mld_ifc_work+0x15d/0x450 [ 3406.223279][T230589] Process_one_work+0x1e6/0x380 [ 3406.232982][T230589] +0x50/0x3a0 [ 3406.242371][T230589] ? hilo_rescate+0x360/0x360 [ 3406.252175][T230589] kthread+0x127/0x150 [ 3406.261197][T230589] ? set_kthread_struct+0x40/0x40 [ 3406.271287][T230589] ret_from_fork+0x22/0x30 [ 3406.280812][T230589] [ 3406.288937][T230589] Módulos vinculados en: ... [última descarga: kheaders] 3406.476714][T230589 ] ---[ final de seguimiento 3525a7655f2f3b9e ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: elimina vsock de la tabla conectada cuando la conexión es interrumpida por una señal vsock_connect() espera que el socket ya esté en el estado TCP_ESTABLISHED cuando la tarea de conexión se activa con una señal pendiente. Si esto sucede, el socket estará en la tabla conectada y no se eliminará cuando se restablezca el estado del socket. En esta situación, es común que el proceso vuelva a intentar conectar() y, si la conexión es exitosa, el socket se agregará a la tabla conectada por segunda vez, corrompiendo la lista. Evite esto llamando a vsock_remove_connected() si se recibe una señal mientras se espera una conexión. Esto es inofensivo si el socket no está en la tabla conectada, y si está en la tabla, eliminarlo evitará la corrupción de la lista debido a una doble adición. Nota para la compatibilidad: este parche requiere d5afa82c977e ("vsock: eliminación correcta del socket de la lista"), que se encuentra en todos los árboles estables actuales excepto 4.9.y.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iwlwifi: corrige el use-after-free Si no había ningún firmware presente (o, presumiblemente, no se pudieron analizar todos los archivos de firmware), terminamos desvinculándolo llamando a device_release_driver( ), que llama a remove(), que luego en iwlwifi llama a iwl_drv_stop(), liberando la estructura 'drv'. Sin embargo, el nuevo código que agregué seguirá accediendo erróneamente a él después de que se haya liberado. Establezca 'failure=false' en este caso para evitar el acceso; todos los datos ya se liberaron de todos modos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-rdma: soluciona el posible use-after-free en el transporte error_recovery work Mientras nvme_rdma_submit_async_event_work verifica el control y el estado de la cola antes de preparar el comando AER y programar io_work, para evitar completamente una ejecución donde esta verificación no es confiable, el trabajo de recuperación de errores debe eliminar async_event_work antes de continuar destruyendo la cola de administración después de configurar el estado de control en RESETTING de manera que no haya ejecución .submit_async_event y el propio controlador de recuperación de errores cambie el estado de control.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-tcp: soluciona el posible use-after-free en el transporte error_recovery work Mientras nvme_tcp_submit_async_event_work verifica el control y el estado de la cola antes de preparar el comando AER y programar io_work, para evitar completamente una ejecución donde esta verificación no es confiable, el trabajo de recuperación de errores debe eliminar async_event_work antes de continuar destruyendo la cola de administración después de configurar el estado de control en RESETTING de manera que no haya ejecución .submit_async_event y el propio controlador de recuperación de errores cambie el estado de control.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvme: corrige un posible use-after-free en el reinicio del controlador durante la carga. A diferencia de .queue_rq, en .submit_async_event es posible que los controladores no verifiquen la preparación de Ctrl para el envío de AER. Esto puede provocar una condición de use-after-free que se observó con nvme-tcp. La condición de ejecución puede ocurrir en el siguiente escenario: 1. el controlador ejecuta su reset_ctrl_work 2. -> nvme_stop_ctrl - vacía ctrl async_event_work 3. ctrl envía AEN que es recibido por el host, que a su vez programa el manejo de AEN 4. desmontaje de la cola de administración (que libera el socket de la cola) 5. AEN procesado, envía otro AER, llamando al controlador para enviar 6. el controlador intenta enviar el cmd ==> use-after-free Para solucionar eso, agregue la verificación de estado de ctrl para validar que ctrl es realmente capaz de aceptar la presentación de la ARE. Esto soluciona la ejecución anterior en los reinicios del controlador porque el controlador durante el desmontaje debe: 1. cambiar el estado de Ctrl a RESTABLECER 2. vaciar async_event_work (así como otros elementos de trabajo asíncronos) Entonces, después de 1,2, cualquier otro comando AER encontrará el estado de Ctrl estar RESETING y rescatar sin presentar la AER.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: pm8001: Corrección de use-after-free para TMF sas_task abortada Actualmente, puede ocurrir un use-after-free si se cancela una TMF sas_task antes de que manejemos la finalización de IO en mpi_ssp_completion( ). El aborto se produce debido al tiempo de espera. Cuando se agota el tiempo de espera, se establece el indicador SAS_TASK_STATE_ABORTED y sas_task se libera en pm8001_exec_internal_tmf_task(). Sin embargo, si la finalización de E/S se produce más tarde, la finalización de E/S todavía piensa que sas_task está disponible. Solucione este problema borrando la tarea ccb-> si se agota el tiempo de espera del TMF; el controlador de finalización de E/S no hace nada si se borra este puntero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: pm8001: Corrige el use-after-free para sas_task SSP/STP abortado. Actualmente, puede ocurrir un use-after-free si la capa superior cancela una sas_task antes de que manejemos el Finalización de E/S en mpi_ssp_completion() o mpi_sata_completion(). En este caso, los siguientes son los dos pasos para manejar esas finalizaciones de E/S: - Llamar a complete() para informar al controlador de la capa superior de la finalización de la E/S. - Liberar los recursos del controlador asociados con sas_task en la llamada pm8001_ccb_task_free(). Cuando se llama a complete(), la capa superior puede liberar sas_task. Como tal, no debemos tocar el sas_task asociado después, pero lo hacemos en la llamada pm8001_ccb_task_free(). Se soluciona intercambiando el orden de las llamadas complete() y pm8001_ccb_task_free().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: parsers: qcom: corrige el pánico del kernel en la partición omitida En el caso de una partición omitida (caso cuando el nombre de la entrada está vacío), el kernel entra en pánico en la función de limpieza como el nombre la entrada es NULA. Vuelva a trabajar la lógica del analizador verificando primero el número de partición real y luego asigne el espacio y configure los datos para las particiones válidas. La lógica también era fundamentalmente errónea, ya que con una partición omitida, el número de pieza devuelto era incorrecto al no disminuirlo para las particiones omitidas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: ufs: corrige un punto muerto en el controlador de errores Se ha observado el siguiente punto muerto en una configuración de prueba: - Todas las etiquetas asignadas - El controlador de errores SCSI llama a ufshcd_eh_host_reset_handler() - ufshcd_eh_host_reset_handler( ) las colas funcionan que llaman a ufshcd_err_handler() - ufshcd_err_handler() se bloquea de la siguiente manera: Cola de trabajo: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Rastreo de llamadas: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 Schedule+0x12c/0x298 get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/ 0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 _reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 proceso_one_work+0x24c/0x66c trabajador_thread+0x3e8/0xa4c kthread+0x150/ 0x1b4 ret_from_fork+0x10/0x30 Solucione este bloqueo haciendo que ufshcd_exec_dev_cmd() asigne una solicitud reservada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/fixmap: corrige la advertencia de depuración de VM al desasignar La desasignación de una entrada de fixmap se realiza llamando a __set_fixmap() con FIXMAP_PAGE_CLEAR como indicadores. Hoy, powerpc __set_fixmap() llama a map_kernel_page(). map_kernel_page() no está contento cuando se le llama por segunda vez para la misma página. ADVERTENCIA: CPU: 0 PID: 1 en arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper No contaminado 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d- sucio #682 NIP: c0017cd4 LR: c00187f0 CTR: 00000010 REGS: e1011d50 TRAP: 0700 No contaminado (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty) MSR: 00029032 CR: 42000208 XER: 00000000 GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c GPR08: 00001000 b00045a9 00000001 c 0f58460 c0f50000 00000000 c0007e10 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000 PIN [c0017cd4 ] set_pte_at+0xc/0x1e8 LR [c00187f0] map_kernel_page+0x9c/0x100 Seguimiento de llamadas: [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (no confiable) [e1011e30] [c0165fec] x44 [e1011e40] [c0c13bdc] early_iounmap +0x11c/0x170 [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0 [e1011e90] [c0c03634] do_one_initcall+0x80/0x178 [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4 /0x250 [e1011f20] [c0007e34] kernel_init+0x24/0x140 [e1011f30 ] [c0016268] ret_from_kernel_thread+0x5c/0x64 Volcado de instrucciones: 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 0 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030 Implemente unmap_kernel_page() que borra un pte existente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sunrpc: corrige fugas de recuento de referencias en rpc_sysfs_xprt_state_change Los problemas de fugas de recuento tienen lugar en una ruta de manejo de errores. Cuando el tercer argumento buf no coincide con "fuera de línea", "en línea" o "eliminar", la función simplemente devuelve -EINVAL y se olvida de disminuir el recuento de referencias de un objeto rpc_xprt y un objeto rpc_xprt_switch aumentado en rpc_sysfs_xprt_kobj_get_xprt() y rpc_sysfs_xprt_kobj_get_xprt_switch (), lo que provoca fugas en el recuento de referencias de ambos objetos no utilizados. Solucione este problema saltando a la ruta de manejo de errores etiquetada con out_put cuando buf no coincida con "fuera de línea", "en línea" o "eliminar".