Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: f_fs: corrige el use-after-free para epfile Considere un caso en el que se llama a ffs_func_eps_disable desde ffs_func_disable como parte del cambio de composición y al mismo tiempo se llama a ffs_epfile_release desde el espacio de usuario. ffs_epfile_release liberará el búfer de lectura y llamará a ffs_data_closed, que a su vez destruirá ffs->epfiles y lo marcará como NULL. Mientras esto sucedía, el controlador ya inicializó el archivo ep local en ffs_func_eps_disable, que ahora está liberado y esperando adquirir el spinlock. Una vez adquirido el spinlock, el controlador continúa con el valor obsoleto de epfile e intenta liberar el búfer de lectura ya liberado, lo que provoca un use-after-free. La siguiente es la ilustración de la ejecución: CPU1 CPU2 ffs_func_eps_disable epfiles (copia local) ffs_epfile_release ffs_data_closed if (último archivo cerrado) ffs_data_reset ffs_data_clear ffs_epfiles_destroy spin_lock desreferenciar epfiles Arregle estas ejecucións tomando la copia local de epfiles y asignándola bajo spinlock y si epfiles(local) es null luego actualícelo en ffs->epfiles y finalmente destrúyalo. Ampliar el alcance más allá de la ejecución, proteger las estructuras relacionadas con ep y los accesos concurrentes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qedf: se solucionó el problema de recuento cuando se recibe el logotipo durante TMF. Se observó un seguimiento de llamada de tarea colgada durante el procesamiento del logotipo. [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: RESET LUN emitido... [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0 [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET [ 974.309222 [0000] :00:00.0]:[qedf_initiate_tmf:2438 ]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1. [ 974.309625] host1: informe 016900: Solicitud de logotipo recibida mientras estaba en estado Listo [ 974.309627] host1: informe 016900: Eliminar puerto [ 974.309642] host1: Informe 016900: evento de trabajo 3 [ 974.309644] host1: informe 016900: devolución de llamada lld ev 3 [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport se está cargando, no ejecutando descarga. [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: comando de gestión de tarea exitoso... [ 984.031088] INFORMACIÓN: tarea jbd2/dm-15-8:7645 bloqueada durante más de 120 segundos. [ 984.031136] No contaminado 4.18.0-305.el8.x86_64 #1 [ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080 [ 984.031212] Seguimiento de llamadas: [ 984.031222] __schedule+0x2c4/0x700 [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0 [984.031233]? bit_wait_timeout+0x90/0x90 [ 984.031235] programación+0x38/0xa0 [ 984.031238] io_schedule+0x12/0x40 [ 984.031240] bit_wait_io+0xd/0x50 [ 984.031243] 80 [984.031248] ? free_buffer_head+0x21/0x50 [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0 [ 984.031257] ? init_wait_var_entry+0x50/0x50 [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2] [ 984.031280] kjournald2+0xbd/0x270 [jbd2] [ 984.031284] ? terminar_esperar+0x80/0x80 [984.031291]? commit_timeout+0x10/0x10 [jbd2] [ 984.031294] kthread+0x116/0x130 [ 984.031300] ? kthread_flush_work_fn+0x10/0x10 [ 984.031305] ret_from_fork+0x1f/0x40 Hubo un problema de recuento de referencias cuando se recibe el logotipo durante TMF. Esto lleva a que una de las E/S se cuelgue con el controlador. Arreglar el recuento de árbitros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: myrs: soluciona el fallo en caso de error En myrs_detect(), cs->disable_intr es NULL cuando privdata->hw_init() falla con un valor distinto de cero. En este caso, myrs_cleanup(cs) llamará a un ptr NULL y bloqueará el kernel. [1.105606] myrs 0000:00:03.0: Error de inicialización desconocido 5A [1.105872] myrs 0000:00:03.0: Error al inicializar el controlador [1.106082] ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000000 [1.110774] Seguimiento de llamadas : [1.110950] myrs_cleanup+0xe4/0x150 [myrs] [ 1.111135] myrs_probe.cold+0x91/0x56a [myrs] [ 1.111302] ? DAC960_GEM_intr_handler+0x1f0/0x1f0 [años] [ 1.111500] local_pci_probe+0x48/0x90

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qedf: agregue stag_work a todos los vports Seguimiento de llamadas visto al crear puertos NPIV, solo 32 de 64 se muestran en línea. El trabajo de despedida no se inicializó para vport, por lo tanto, inicialice el trabajo de despedida. ADVERTENCIA: CPU: 8 PID: 645 en kernel/workqueue.c:1635 __queue_delayed_work+0x68/0x80 CPU: 8 PID: 645 Comm: kworker/8:1 Kdump: cargado Contaminado: G IOE --------- -- 4.18.0-348.el8.x86_64 #1 Nombre del hardware: Dell Inc. PowerEdge MX740c/0177V9, BIOS 2.12.2 09/07/2021 Cola de trabajo: eventos fc_lport_timeout [libfc] RIP: 0010:__queue_delayed_work+0x68/0x80 Código : 89 b2 88 00 00 00 44 89 82 90 00 00 00 48 01 c8 48 89 42 50 41 81 f8 00 20 00 00 75 1d e9 60 24 07 00 44 89 c7 e9 98 f6 ff ff <0f> 0b eb c5 0f 0b eb a1 0f 0b eb a7 0f 0b eb ac 44 89 c6 e9 40 23 RSP: 0018:ffffae514bc3be40 EFLAGS: 00010006 RAX: ffff8d25d6143750 RBX: 0000000000000202 RCX: 000000000002 RDX: ffff8d2e31383748 RSI: ffff8d25c000d600 RDI: ffff8d2e31383788 RBP: ffff8d2e31380de0 R08: 0000000000002000 R09 : ffff8d2e31383750 R10: ffffffffc0c957e0 R11: ffff8d2624800000 R12: ffff8d2e31380a58 R13: ffff8d2d915eb000 R14: ffff8d25c499b5c0 R15: 0e18 FS: 0000000000000000(0000) GS:ffff8d2d1fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fd0484b8b8 CR3: 00000008ffc10006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: queue_delayed_work_on+0x36/0x40 qedf_elsct_send+0x57/0x60 [qedf] fc_lport_enter_flogi+0x90/0xc0 [libfc ] fc_lport_timeout+0xb7/0x140 [libfc] Process_one_work+0x1a7/0x360? crear_trabajador+0x1a0/0x1a0 hilo_trabajador+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 008f00f722f2c2ff ]-- Inicializa el trabajo de despedida para todos los vports.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: se corrige el punto muerto en el error de conexión del dispositivo DSI. La conexión del dispositivo DSI al host DSI se realizará con el bloqueo del dispositivo host retenido. Cancelar el registro del host en la ruta de error "conexión de dispositivo" (por ejemplo, reintento de sonda) resultará en un punto muerto con un seguimiento de llamada inferior y una pantalla DSI no operativa. Seguimiento de llamadas de inicio: [35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8 [35.043048] mutex_lock_nested+0x7c/0xc8 [35.043060] device_del+0x4c/0x3e8 [35.043075 dispositivo_unregister+0x20/ 0x40 [35.043082] mipi_dsi_remove_device_fn+0x18/0x28 [35.043093 ] dispositivo_para_cada_niño+0x68/0xb0 [ 35.043105] mipi_dsi_host_unregister+0x40/0x90 [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4] [ 35.043199] mipi_dsi_attach+0x30/0x48 [ 35.043209] tc358762_probe+0x128/0x164 [tc358762] [ 35.043225] mipi_dsi_drv_probe+0x28 /0x38 [ 35.043234] very_probe+0xc0/0x318 [ 35.043244] __driver_probe_device+0x80/0xe8 [ 35.043254] driver_probe_device+0xb8/0x118 [ 35.043263] xe8 [ 35.043273] bus_for_each_drv+0x84/0xd8 [ 35.043281] __device_attach+0xf0/0x150 [ 35.043290] dispositivo_inicial_probe+0x1c/0x28 [ 35.043300] bus_probe_device+0xa4/0xb0 [ 35.043308] diferido_probe_work_func+0xa0/0xe0 [ 35.043318] proceso_one_work+0x254/0x700 [ 35.0 43330] hilo_trabajador+0x4c/0x448 [ 35.043339] kthread+0x19c/0x1a8 [ 35.043348 ] ret_from_fork+0x10/0x20 Apagado Rastreo de llamadas: [ 365.565417] Rastreo de llamadas: [ 365.565423] __switch_to+0x148/0x200 [ 365.565452] __schedule+0x340/0x9c8 [ 365.565467] 0x110 [365.565479] timeout_programado+0x3b0/0x448 [365.565496 ] wait_for_completion+0xac/0x138 [ 365.565509] __flush_work+0x218/0x4e0 [ 365.565523] flush_work+0x1c/0x28 [ 365.565536] wait_for_device_probe+0x68/0x158 [ 365.565550] _shutdown+0x24/0x348 [ 365.565561] kernel_restart_prepare+0x40/0x50 [ 365.565578] kernel_restart +0x20/0x70 [ 365.565591] __do_sys_reboot+0x10c/0x220 [ 365.565605] __arm64_sys_reboot+0x2c/0x38 [ 365.565619] invoke_syscall+0x4c/0x110 [ 365.56563 4] el0_svc_common.constprop.3+0xfc/0x120 [ 365.565648] do_el0_svc+0x2c/0x90 [ 365.565661 ] el0_svc+0x4c/0xf0 [ 365.565671] el0t_64_sync_handler+0x90/0xb8 [ 365.565682] el0t_64_sync+0x180/0x184

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: corrige el comportamiento de READ cerca de OFFSET_MAX Dan Aloni informa: > Debido a El commit 8cfb9015280d ("NFS: siempre proporcione buffers alineados a > las capas de lectura RPC") en el cliente, una lectura de 0xfff está alineada con el tamaño del servidor de 0x1000. > > Como resultado, en una prueba donde el servidor tiene un archivo de tamaño > 0x7ffffffffffffffff, y el cliente intenta leer desde el desplazamiento > 0x7ffffffffffffff000, la lectura causa que loff_t se desborde en el servidor > y devuelve un código NFS de EINVAL a el cliente. Como resultado, el cliente reintenta indefinidamente la solicitud. El cliente NFS de Linux no maneja NFS?ERR_INVAL, aunque todas las especificaciones de NFS permiten a los servidores devolver ese código de estado para una READ. En lugar de NFS?ERR_INVAL, haga que las solicitudes READ fuera de rango se realicen correctamente y devuelvan un resultado breve. Establezca el indicador EOF en el resultado para evitar que el cliente vuelva a intentar la solicitud READ. Este comportamiento parece ser coherente con los servidores Solaris NFS. Tenga en cuenta que NFSv3 y NFSv4 utilizan valores de compensación u64 en el cable. Estos deben convertirse a loff_t internamente antes de su uso; una conversión de tipo implícita no es adecuada para este propósito. De lo contrario, las comprobaciones de VFS con sb->s_maxbytes no funcionan correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: isotp: corrige una posible ejecución de recepción de tramas CAN en isotp_rcv() Al recibir una trama CAN, la lógica del código actual no considera la recepción simultánea de procesos que no aparecen en el uso en el mundo real. Ziyang Xuan escribe: El siguiente problema syz es uno de los escenarios. so->rx.len es cambiado por isotp_rcv_ff() durante isotp_rcv_cf(), so->rx.len es igual a 0 antes de alloc_skb() y es igual a 4096 después de alloc_skb(). Eso activará skb_over_panic() en skb_put(). ==================================================== ===== CPU: 1 PID: 19 Comm: ksoftirqd/1 No contaminado 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 Seguimiento de llamadas: skb_over_panic net/core/skbuff.c:118 [en línea] skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [en línea] isotp_rcv+0xa38/0x1e30 net/ can/isotp.c:668 entregar net/can/af_can.c:574 [en línea] can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665 can_rcv+ 0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Por lo tanto, nos aseguramos de que los cambios de estado y las estructuras de datos mantenga la coherencia en el momento de recepción de la trama CAN agregando un spin_lock en isotp_rcv(). Esto soluciona el problema informado por syzkaller pero no afecta el funcionamiento en el mundo real.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ima: corrige la fuga de referencia en ametric_verify() No filtre una referencia a la clave si se desconoce su algoritmo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: auditoría: no desreferenciar los argumentos de syscall al verificar openat2 open_how::flags Según lo informado por Jeff, desreferenciar el argumento de openat2 syscall en audit_match_perm() para obtener open_how::flags puede resultar en un error de página/ups. Este parche soluciona este problema utilizando la estructura open_how que almacenamos en audit_context con audit_openat2_how(). Independientemente de este parche, Richard Guy Briggs publicó un parche similar en la lista de correo de auditoría aproximadamente 40 minutos después de la publicación de este parche.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFSD: corrija el desbordamiento insuficiente de ia_size iattr::ia_size es un loff_t, que es un tipo de 64 bits firmado. NFSv3 y NFSv4 definen el tamaño del archivo como un tipo de 64 bits sin firmar. Por lo tanto, existe un rango de valores de tamaño de archivo válidos que un cliente NFS puede enviar y que ya es mayor de lo que Linux puede manejar. Actualmente, decode_fattr4() vuelca un valor u64 completo en ia_size. Si ese valor resulta ser mayor que S64_MAX, entonces ia_size tiene un desbordamiento insuficiente. También estoy a punto de arreglar el comportamiento de NFSv3, así que detectemos el desbordamiento en la ruta del código común: nfsd_setattr().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: corrige el manejo de NFSv3 SETATTR/CREATE de archivos de gran tamaño iattr::ia_size es un loff_t, por lo que estos procedimientos de NFSv3 deben tener cuidado al tratar con valores de tamaño de cliente entrantes que son mayores que s64_max sin corromper el valor. Limitar silenciosamente el valor da como resultado que se almacene un valor diferente al que pasó el cliente, lo cual es un comportamiento inesperado, por lo tanto, elimine la verificación min_t() en decode_sattr3(). Tenga en cuenta que RFC 1813 sólo permite que el procedimiento WRITE devuelva NFS3ERR_FBIG. Creemos que las implementaciones de referencia de NFSv3 también devuelven NFS3ERR_FBIG cuando ia_size es demasiado grande.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ice: Solucionar error KASAN en el controlador LAG NETDEV_UNREGISTER Actualmente, se llama al mismo controlador tanto para una notificación de desvinculación de NETDEV_BONDING_INFO LAG como para una llamada NETDEV_UNREGISTER. Sin embargo, esto está causando un problema, ya que el netdev_notifier_info pasado tiene una estructura diferente según el evento que se pasa. El problema se manifiesta como un seguimiento de llamada de un ERROR: error de pila fuera de los límites de KASAN. Solucione este problema creando un controlador específico para NETDEV_UNREGISTER al que solo se le pasan elementos válidos en la estructura netdev_notifier_info para el evento NETDEV_UNREGISTER. También se incluye la eliminación de un dev_put desequilibrado en peer_netdev y llaves relacionadas.