Vulnerabilidades

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().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/core: Establecer el CQ de envío y recepción antes de reenviar al controlador Preestablecer los punteros CQ de envío y recepción antes de llamar a los controladores y sobrescribirlos más tarde nuevamente hasta que se vaya a cambiar mlx4 no sobrescribir las propiedades ibqp. Este cambio es necesario para mlx5, porque en caso de falla en la creación de QP, irá a la ruta de destrucción de QP que depende de punteros CQ adecuados. BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib] Write of size 8 at addr ffff8880064c55c0 by task a.out/246 CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x83/0xdf create_qp.cold+0x164/0x16e [mlx5_ib] mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib] create_qp.part.0+0x45b/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 246: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0xa4/0xd0 create_qp.part.0+0x92/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 246: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x10c/0x150 slab_free_freelist_hook+0xb4/0x1b0 kfree+0xe7/0x2a0 create_qp.part.0+0x52b/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: anular el puntero cq->dbg en mlx5_debug_cq_remove() Antes de este parche, en caso de que mlx5_core_destroy_cq() fallara, se procedía al resto de las operaciones de destrucción. El usuario podía volver a llamar a mlx5_core_destroy_cq() y provocar una llamada adicional de mlx5_debug_cq_remove(). cq->dbg no se anuló en la llamada anterior y provocó el bloqueo. Arréglelo anulando el puntero cq->dbg después de la eliminación. También proceda a destruir las operaciones solo si el firmware devuelve 0 para el comando MLX5_CMD_OP_DESTROY_CQ. Fallo de protección general, probablemente por dirección no canónica 0x2000300004058:0000 [#1] SMP PTI CPU: 5 PID: 1228 Comm: python No contaminado 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockref_get+0x1/0x60 Código: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02 00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 <48> 8b 17 48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48 RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206 RAX: 000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffe RDX: 00000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058 RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000 R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0 FS: 00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0 Seguimiento de llamadas: simple_recursive_removal+0x33/0x2e0 ? debugfs_remove+0x60/0x60 debugfs_remove+0x40/0x60 mlx5_debug_cq_remove+0x32/0x70 [mlx5_core] mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core] devx_obj_cleanup+0x151/0x330 [mlx5_ib] ? __pollwait+0xd0/0xd0 ? xas_load+0x5/0x70 ? uverbs_destruir_uobject+0x3b/0x360 [ib_uverbs] uobj_destruir+0x54/0xa0 [ib_uverbs] ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs] ? uverbs_finalizar_objeto+0xd0/0xd0 [ib_uverbs] ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs] __x64_sys_ioctl+0x3e4/0x8e0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Fix use-after-free en la rutina lpfc_unreg_rpi() Se detecta un error con el siguiente reporte al descargar el driver: "KASAN: use-after-free en lpfc_unreg_rpi +0x1b1b" El NLP_REG_LOGIN_SEND nlp_flag está configurado en lpfc_reg_fab_ctrl_node(), pero el indicador no se borra al finalizar el inicio de sesión. Esto permite una segunda llamada a lpfc_unreg_rpi() para continuar con nlp_rpi configurado en LPFC_RPI_ALLOW_ERROR. Esto da como resultado un acceso de use after free cuando se usa como índice de matriz rpi_ids. Para solucionarlo, borre NLP_REG_LOGIN_SEND nlp_flag en lpfc_mbx_cmpl_fc_reg_login().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Se soluciona el procesamiento de enlace inactivo para abordar la desreferencia de puntero NULL Si una transición de enlace inactivo FC mientras hay PLOGI pendientes para direcciones conocidas de Fabric, las solicitudes ABTS pendientes pueden resultar en una desreferencia de puntero NULL. Las solicitudes de descarga del controlador pueden bloquearse con mensajes de registro "2878" repetidos. El procesamiento de enlace inactivo da como resultado solicitudes ABTS para solicitudes ELS pendientes. Los WQE de cancelación se envían para los ELS antes de que el controlador haya establecido el estado del enlace en inactivo. Por lo tanto, el controlador envía la cancelación con la expectativa de que se envíe una ABTS en el cable. La solicitud de cancelación se detiene esperando que se active el enlace. En algunas condiciones, el controlador puede completar automáticamente los ELS, por lo que si el enlace se activa, las finalizaciones de cancelación pueden hacer referencia a una estructura no válida. Se soluciona asegurándose de que la cancelación establezca el indicador para evitar el tráfico de enlace si se emite debido a condiciones en las que el enlace falló.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: pm80xx: se corrigió la pérdida de memoria durante rmmod, el controlador no pudo liberar toda la memoria asignada. Esto puede provocar una pérdida de memoria durante la eliminación del controlador. Se debe liberar correctamente la memoria cuando se retire el módulo.