Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: Fix scsi_mode_sense() buffer length management Existen varios problemas con el manejo de la longitud del búfer de scsi_mode_sense(): 1) El campo de longitud de asignación del comando MODE SENSE(10) es de 16 bits y ocupa los bytes 7 y 8 del CDB. Con este comando, es posible acceder a páginas de modo mayores de 255 bytes. Sin embargo, el campo de longitud de asignación del CDB se establece asignando len solo al byte 8, truncando así la longitud del búfer mayor de 255. 2) Si se llama a scsi_mode_sense() con len menor que 8 con sdev->use_10_for_ms establecido, o menor que 4 en caso contrario, la longitud del búfer aumenta a 8 y 4 respectivamente, y el búfer se rellena con ceros con estos valores aumentados, corrompiendo así la memoria que sigue al búfer. Solucione estos 2 problemas usando put_unaligned_be16() para configurar el campo de longitud de asignación de MODE SENSE(10) CDB y devolviendo un error cuando len sea demasiado pequeño. Además, si len es mayor que 255B, siempre intente MODE SENSE(10) primero, incluso si el controlador del dispositivo no configuró sdev->use_10_for_ms. En caso de error de código de operación no válido para MODE SENSE(10), el acceso a páginas de modo mayores a 255 bytes no se vuelve a intentar usando MODE SENSE(6). Para evitar desbordamientos de longitud de búfer para el caso de MODE_SENSE(10), verifique que len sea menor a 65535 bytes. Mientras lo hace, también solucione lo siguiente: * Use get_unaligned_be16() para recuperar los campos de longitud de datos de modo y longitud de descriptor de bloque del encabezado de respuesta de sentido de modo en lugar de usar un cálculo de código abierto. * Corregir la explicación del argumento dbd de kdoc: el bit DBD significa Deshabilitar descriptor de bloque, que es lo opuesto a lo que era la descripción del argumento dbd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Corregir la desreferencia de puntero nulo en la sincronización de filtros VSI Eliminar el motivo de la desreferencia de puntero nulo en los filtros VSI de sincronización. Se ha añadido el nuevo indicador I40E_VSI_RELEASING para señalar la eliminación y liberación de recursos VSI para sincronizar este hilo con la subtarea de filtros de sincronización. Sin este parche, es posible comenzar a actualizar la lista de filtros VSI después de que se elimine VSI, lo que provoca un error en el kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: tty_buffer: soluciona el problema de bloqueo suave en flush_to_ldisc Al ejecutar ltp testcase(ltp/testcases/kernel/pty/pty04.c) con arm64, hay un bloqueo suave, que se parece a este: Workqueue: events_unbound flush_to_ldisc Rastreo de llamadas: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120 En el caso de prueba pty04, el primer proceso llama a la escritura Llamada al sistema para enviar datos al maestro pty. Al mismo tiempo, la cola de trabajo ejecutará el comando flush_to_ldisc para extraer los datos en un bucle hasta que no queden más datos. Cuando el remitente y la cola de trabajo se ejecutan en núcleos diferentes, el remitente envía datos rápidamente en tiempo completo, lo que hará que la cola de trabajo realice el trabajo en bucle durante mucho tiempo y se produzca un bloqueo suave en flush_to_ldisc con el núcleo configurado sin interrupción. Por lo tanto, agrego la comprobación need_resched y cond_resched en el bucle flush_to_ldisc para evitarlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tipc: verifique si hay valores nulos después de llamar a kmemdup kmemdup puede devolver un puntero nulo, por lo que es necesario verificarlo; de lo contrario, se eliminará la referencia a la clave nula más adelante en tipc_crypto_key_xmit, como se puede ver en el seguimiento. [1]. [1] https://syzkaller.appspot.com/bug?id=bca180abb29567b189efdbdb34cbf7ba851c2a58

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: dts: qcom: msm8998: Se corrige la latencia y residencia del estado inactivo de la CPU/L2 La latencia de entrada/salida y la residencia mínima en el estado para los estados inactivos de MSM8998 eran... malas: en primer lugar, para todos ellos, los tiempos se escribieron para el sueño de la CPU, pero el parámetro min-residency-us se calculó mal (supuestamente, al portar esto desde el lado descendente); luego, los estados de colapso de energía están configurando PC tanto en el clúster de la CPU *como* en el caché L2, que tienen diferentes tiempos: en el caso específico de L2, los tiempos son más altos, por lo que estos deben tenerse en cuenta en lugar de los de la CPU. Esta configuración incorrecta de parámetros no estaba dando problemas particulares porque en MSM8998 no había escalamiento de la CPU en absoluto, por lo que el colapso de energía del clúster/L2 rara vez (o nunca) se veía afectado. Sin embargo, cuando el escalado de CPU está habilitado, los tiempos incorrectos producirán inestabilidad del SoC, que se mostrará al usuario como reinicios y/o bloqueos repentinos aleatorios, aparentemente sin errores. Este conjunto de parámetros estabiliza el SoC cuando el escalado de CPU está activado y cuando se producen caídas de energía con frecuencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Mejorar el manejo de la interrupción de SCSI Se ha observado lo siguiente en una configuración de prueba: ADVERTENCIA: CPU: 4 PID: 250 en drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c Rastreo de llamadas: ufshcd_queuecommand+0x468/0x65c scsi_send_eh_cmnd+0x224/0x6a0 scsi_eh_test_devices+0x248/0x418 scsi_eh_ready_devs+0xc34/0xe58 scsi_error_handler+0x204/0x80c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 Esa advertencia se activa por lo siguiente: declaración: WARN_ON(lrbp->cmd); Corrija esta advertencia borrando lrbp->cmd del controlador de aborto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arreglo del ordenamiento de memoria entre funciones de trabajo normales y ordenadas No se garantiza que las funciones de trabajo ordenadas sean manejadas por el mismo hilo que ejecutó las funciones de trabajo normales. La única forma de sincronizar la ejecución entre funciones normales/ordenadas es a través de WORK_DONE_BIT, desafortunadamente los bitops utilizados no garantizan ningún orden. Esto se manifestó como fallas aparentemente inexplicables en ARM64, donde async_chunk::inode se ve como no nulo en async_cow_submit, lo que hace que se llame a submission_compressed_extents y se produce una falla porque async_chunk::inode de repente se volvió NULL. El seguimiento de llamadas fue similar a: pc : submission_compressed_extents+0x38/0x3d0 lr : async_cow_submit+0x50/0xd0 sp : ffff800015d4bc20 Seguimiento de llamadas: submission_compressed_extents+0x38/0x3d0 async_cow_submit+0x50/0xd0 run_ordered_work+0xc8/0x280 btrfs_work_helper+0x98/0x250 process_one_work+0x1f0/0x4ac worker_thread+0x188/0x504 kthread+0x110/0x114 ret_from_fork+0x10/0x18 Solucione esto agregando las llamadas de barrera respectivas que garantizan que todos los accesos anteriores a la configuración de Los bits WORK_DONE_BIT se ordenan estrictamente antes de establecer la bandera. Al mismo tiempo, agregue una barrera de lectura después de la lectura de WORK_DONE_BIT en run_ordered_work que garantiza que todas las cargas posteriores se ordenarán estrictamente después de leer el bit. Esto, a su vez, garantiza que todos los accesos antes de WORK_DONE_BIT se ordenarán estrictamente antes de cualquier acceso que pueda ocurrir en ordered_func.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf bpf: Evitar pérdida de memoria de perf_env__insert_btf() perf_env__insert_btf() no se inserta si se encuentra un ID de BTF duplicado y esto provoca una pérdida de memoria. Modifique la función para que devuelva un valor de éxito/error y luego libere la memoria si la inserción no ocurrió. v2. Agrega un retorno -1 cuando ocurre el error de inserción en perf_env__fetch_btf. Esto no afecta a nada ya que el resultado nunca se verifica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: Se corrige la lectura fuera de los límites en resp_readcap16(). Se observó la siguiente advertencia al ejecutar syzkaller: [ 3813.830724] sg_write: datos de entrada/salida 65466/242 bytes para el comando SCSI 0x9e-- adivinando datos de entrada; [ 3813.830724] El programa syz-executor no establece count y/o reply_len correctamente [ 3813.836956] ====================================================================== [ 3813.839465] ERROR: KASAN: pila fuera de los límites en sg_copy_buffer+0x157/0x1e0 [ 3813.841773] Lectura de tamaño 4096 en la dirección ffff8883cf80f540 por la tarea syz-executor/1549 [ 3813.846612] Seguimiento de llamadas: [ 3813.846995] dump_stack+0x108/0x15f [ 3813.847524] print_address_description+0xa5/0x372 [ 3813.848243] kasan_report.cold+0x236/0x2a8 [ 3813.849439] check_memory_region+0x240/0x270 [ 3813.850094] memcpy+0x30/0x80 [ 3813.850553] sg_copy_buffer+0x157/0x1e0 [ 3813.853032] sg_copy_from_buffer+0x13/0x20 [ 3813.853660] llenar_desde_buffer_dev+0x135/0x370 [ 3813.854329] resp_readcap16+0x1ac/0x280 [ 3813.856917] schedule_resp+0x41f/0x1630 [ 3813.858203] comando_cola_de_depuración_scsi+0xb32/0x17e0 [ 3813.862699] comando_envío_scsi+0x330/0x950 [ 3813.863329] función_solicitud_scsi+0xd8e/0x1710 [ 3813.863946] cola_ejecución_blk+0x10b/0x230 [ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400 [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420 [ 3813.871637] sg_write+0x6c8/0xef0 [ 3813.878853] __vfs_write+0xe4/0x800 [ 3813.883487] vfs_write+0x17b/0x530 [ 3813.884008] ksys_write+0x103/0x270 [ 3813.886268] __x64_sys_write+0x77/0xc0 [ 3813.886841] do_syscall_64+0x106/0x360 [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Este problema se puede reproducir con el siguiente registro de syzkaller: r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0) r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00') open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000) r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782) escribir$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126) En resp_readcap16() obtenemos el valor "int alloc_len" -1104926854, y luego pasamos la enorme arr_len se usa para fill_from_dev_buffer(), pero arr solo tiene 32 bytes. Esto genera OOB en sg_copy_buffer(). Para resolver este problema, defina alloc_len como u32.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: sysfs: Fix hang when device state is set via sysfs Esto corrige una regresión agregada con: commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device") El problema es que después de la recuperación de iSCSI, iscsid llamará al kernel para establecer el estado del dev en running, y con ese parche ahora llamamos a scsi_rescan_device() con el state_mutex retenido. Si el hilo del controlador de errores SCSI está empezando a probar el dispositivo en scsi_send_eh_cmnd() entonces va a intentar capturar el state_mutex. Entonces estamos atascados, porque cuando scsi_rescan_device() intenta enviar su E/S, scsi_queue_rq() llama a -> scsi_host_queue_ready() -> scsi_host_in_recovery() que devolverá verdadero (el estado del host todavía está en recuperación) y la E/S simplemente se volverá a poner en cola. scsi_send_eh_cmnd() nunca podrá tomar el state_mutex para finalizar el manejo de errores. Para evitar el punto muerto, mueva el código relacionado con el rescan a después de que eliminemos el state_mutex. Esto también agrega una verificación para ver si ya estamos en el estado de ejecución. Esto evita escaneos adicionales y ayuda al caso iscsid donde si la clase de transporte ya ha puesto en línea el dispositivo durante su proceso de recuperación, entonces no necesitamos espacio de usuario para hacerlo nuevamente y posiblemente bloquear ese daemon.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cfg80211: llame a cfg80211_stop_ap cuando cambie del tipo P2P_GO. Si las herramientas del espacio de usuario cambian de NL80211_IFTYPE_P2P_GO a NL80211_IFTYPE_ADHOC mediante send_msg(NL80211_CMD_SET_INTERFACE), no llama a la limpieza cfg80211_ stop_ap(), esto lleva a la inicialización de datos en uso. Por ejemplo, esta ruta reinicia sdata->assigned_chanctx_list mientras todavía es un elemento de la lista asignada_vifs y corrompe esa lista vinculada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: corrige el use-after-free del mutex add_lock. El commit 6098475d4cb4 ("spi: corrige el punto muerto al agregar controladores SPI en buses SPI") introdujo un mutex por controlador. Pero mutex_unlock() de dicho bloqueo se llama después de que el controlador ya está liberado: spi_unregister_controller(ctlr) -> put_device(&ctlr->dev) -> spi_controller_release(dev) -> mutex_unlock(&ctrl->add_lock) Mueva put_device() después el mutex_unlock().