Vulnerabilidades

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: wifi: iwlwifi: mvm: soluciona un fallo cuando nos quedamos sin estaciones Una herramienta DoS que inyecta un montón de marcos de autenticación hacía que nuestro AP fallara. La función iwl_mvm_is_dup() no pudo encontrar los datos dup_data por cola que no estaban asignados. La causa principal de esto es que nos quedamos sin estaciones en el firmware y realmente no agregamos la estación al firmware, pero no devolvimos un error a mac80211. Mac80211 estaba pensando que teníamos la estación y debido a eso, sta_info::uploaded se configuró en 1. Esto permitió que ieee80211_find_sta_by_ifaddr() devolviera un objeto de estación válido, pero que ieee80211_sta no tenía ningún objeto iwl_mvm_sta inicializado y eso causó el bloqueo. Mencioné anteriormente cuando obtuvimos Rx en esa estación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: corrige el error de doble liberación El almacenamiento de los datos de registro de PC TLV no se realizó como el resto del almacenamiento en el área drv->fw, que se borra en el fin de la desasignación. Por lo tanto, la liberación también debe realizarse de manera diferente, anulándolo explícitamente después de la liberación, ya que de lo contrario hay un desagradable error de doble liberación aquí si un archivo no se carga después de haber sido analizado y obtenemos otra liberación más tarde (por ejemplo porque no existe ningún otro archivo). Solucione el problema agregando la asignación NULL que falta.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: ccp - Corrige la desreferencia del puntero nulo en __sev_platform_shutdown_locked El dispositivo de la plataforma SEV se puede apagar con un psp_master nulo, por ejemplo, usando DEBUG_TEST_DRIVER_REMOVE. Encontrado usando KASAN: [ 137.148210] ccp 0000:23:00.1: dispositivo de habilitación (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no hay colas de comandos disponibles [ 137.170598] ccp 0000:23:00.1: sev habilitado [ 13 7.174645 ] ccp 0000:23:00.1: psp habilitado [137.178890] falla de protección general, probablemente para dirección no canónica 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [137.182693] KASAN: null-ptr-deref en rango [0x00 000000000000f0- 0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 No contaminado 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.1826 93] Código: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 00000000000000000 RC X: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R0 8 : 0000000000000000 R09: ffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881 e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:00000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693 ] Seguimiento de llamadas: [ 137.182693] [ 137.182693] ? show_regs+0x6c/0x80 [137.182693]? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [137.182693]? asm_exc_general_protection+0x2b/0x30 [137.182693]? __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [ 137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0 xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [ 137.182693] device_remove+0xc7/0x170 [ 137.182693]realmente_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.18 2693] ? __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10 [137.182693]? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [137.182693]? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_ registro_controlador+0x1d6/0x2a0 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693]? esrt_sysfs_init+0x1cd/0x5d0 [137.182693]? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [137.182693]? parameq+0x80/0xf0 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693]? __kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernel_init_freeable+0x92d/0x1050 [137.182693]? kasan_populate_vmalloc_pte+0x171/0x190 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693] kernel_init_freeable+0xa64/0x1050 [137.182693]? __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x1 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige un bloqueo en nilfs_lookup_dirty_data_buffers() Syzbot informó un problema de bloqueo en migrar_pages_batch() llamado por mbind() y nilfs_lookup_dirty_data_buffers() llamado en el escritor de registros de nilfs2. Mientras migrar_pages_batch() bloquea una publicación y espera a que se complete la reescritura, el subproceso del escritor de registros que debería completar la reescritura recoge la publicación que se está reescribiendo en nilfs_lookup_dirty_data_buffers() que solicita la creación de registros posteriores y estaba intentando bloquear la fol. Provocando así un punto muerto. En primer lugar, es inesperado que los folios/páginas en medio de la reescritura se actualicen y se ensucien. Nilfs2 agrega una suma de verificación para verificar la validez del registro que se está escribiendo y la usa para la recuperación en el montaje, de modo que se suprimen los cambios de datos durante la reescritura. Dado que esto no funciona, un cierre incorrecto podría provocar que falle la recuperación. La investigación reveló que la causa principal es que la espera para que se complete la reescritura en nilfs_page_mkwrite() es condicional, y si el dispositivo de respaldo no requiere escrituras estables, los datos se pueden modificar sin esperar. Solucione estos problemas haciendo que nilfs_page_mkwrite() espere a que finalice la reescritura independientemente del requisito de escritura estable del dispositivo de respaldo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hv_netvsc: corrige la condición de ejecución entre netvsc_probe y netvsc_remove En el commit ac5047671758 ("hv_netvsc: deshabilite NAPI antes de cerrar el canal VMBus"), se llamaba a napi_disable para todos los canales, incluidos todos los subcanales sin confirmando si están habilitados o no. Esto provocó que hv_netvsc se colgara en napi_disable, cuando netvsc_probe() terminó de ejecutarse pero nvdev->subchan_work aún no se inició. netvsc_subchan_work() -> rndis_set_subchannel() no ha creado los subcanales y por eso netvsc_sc_open() no se está ejecutando. netvsc_remove() llama a cancel_work_sync(&nvdev->subchan_work), para lo cual netvsc_subchan_work no se ejecutó. netif_napi_add() establece el bit NAPI_STATE_SCHED porque garantiza que NAPI no se pueda programar. Luego netvsc_sc_open() -> napi_enable borrará el bit NAPIF_STATE_SCHED, para que pueda programarse. napi_disable() hace lo contrario. Ahora, durante netvsc_device_remove(), cuando se llama a napi_disable para esos subcanales, napi_disable se atasca en msleep infinito. Esta solución soluciona este problema garantizando que no se llame a napi_disable() para una estructura NAPI no habilitada. Pero netif_napi_del() sigue siendo necesario para estas estructuras NAPI no habilitadas con fines de limpieza. Rastreo de llamadas: [654.559417] tarea:modprobe estado:D pila: 0 pid: 2321 ppid: 1091 banderas:0x00004002 [654.568030] Rastreo de llamadas: [654.571221] [654.573790] __schedule+0x2d6/0x960 [ 65 4.577733] horario+0x69 /0xf0 [654.581214] Schedule_timeout+0x87/0x140 [654.585463]? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 6 54.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [654.611101]? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: evita el use-after-free en encode_cap_msg() En fs/ceph/caps.c, en encode_cap_msg(), KASAN detectó el error "use after free" en este línea - 'ceph_buffer_get(arg->xattr_buf);'. Esto implica que antes de que el recuento pudiera incrementarse aquí, fue liberado. En el mismo archivo, en "handle_cap_grant()", el refcount se reduce en esta línea: 'ceph_buffer_put(ci->i_xattrs.blob);'. Parece que se produjo una ejecución y la última línea liberó el recurso antes de que la primera línea pudiera incrementarlo. __send_cap() llama a encode_cap_msg() y ceph_check_caps() llama a __send_cap() después de llamar a __prep_cap(). __prep_cap() es donde arg->xattr_buf se asigna a ci->i_xattrs.blob. Este es el punto donde se debe aumentar el recuento para evitar el error "use after free".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: protege las actualizaciones de los contadores de estadísticas de 64 bits. Como se explica en un comentario en , el lado de escritura de la estructura u64_stats_sync debe garantizar la exclusión mutua, o uno La actualización de seqcount podría perderse en plataformas de 32 bits, bloqueando así a los lectores para siempre. Estos bloqueos se han observado en el mundo real después de que stmmac_xmit() en una CPU compitiera con stmmac_napi_poll_tx() en otra CPU. Para solucionar el problema sin introducir un nuevo bloqueo, divida la estática en tres partes: 1. campos actualizados solo bajo el bloqueo de la cola de transmisión, 2. campos actualizados solo durante la encuesta NAPI, 3. campos actualizados solo desde el contexto de interrupción, Actualizaciones de los campos en los dos primeros grupos ya están serializados a través de otras cerraduras. Basta con dividir la estructura existente u64_stats_sync para que cada grupo tenga el suyo propio. Tenga en cuenta que tx_set_ic_bit se actualiza desde ambos contextos. Divida este contador para que cada contexto tenga el suyo y calcule su suma para obtener el valor total en stmmac_get_ethtool_stats(). Para el tercer grupo, diferentes CPU pueden procesar múltiples interrupciones al mismo tiempo, pero las interrupciones en la misma CPU no se anidarán. Mueva los campos de este grupo a una estructura por CPU stmmac_pcpu_stats recién creada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb: se corrigió la regresión en las escrituras cuando se negoció un tamaño de escritura máximo no estándar. La conversión a netfs en el kernel 6.3 provocó una regresión cuando el servidor estableció el tamaño de escritura máximo en un valor inesperado. que no es un múltiplo de 4096 (de manera similar, si el usuario anula el tamaño máximo de escritura configurando el parámetro de montaje "wsize", pero lo establece en un valor que no es un múltiplo de 4096). Cuando el tamaño de escritura negociado no es un múltiplo de 4096, el código netfs puede omitir el final de la página final al realizar escrituras secuenciales grandes, lo que provoca corrupción de datos. Esta sección de código se está reescribiendo/eliminando debido a un gran cambio en netfs, pero hasta ese momento (es decir, para el kernel 6.3 hasta ahora) no podemos admitir tamaños máximos de escritura no estándar. Agregue una advertencia si un usuario especifica un wsize en el montaje que no es un múltiplo de 4096 (y redondea hacia abajo), también agregue un cambio donde redondeamos hacia abajo el tamaño máximo de escritura si el servidor negocia un valor que no es un múltiplo de 4096 ( también tenemos que comprobar que no lo redondeamos a cero).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige la corrupción de datos en la recuperación de bloques dsync para tamaños de bloques pequeños La función auxiliar nilfs_recovery_copy_block() de nilfs_recovery_dsync_blocks(), que recupera datos de los registros creados por escrituras de sincronización de datos durante un montaje después un apagado incorrecto calcula incorrectamente el desplazamiento en la página al copiar los datos de reparación en la memoria caché de la página del archivo. En entornos donde el tamaño del bloque es menor que el tamaño de la página, esta falla puede causar corrupción de datos y pérdida de bytes de memoria no inicializados durante el proceso de recuperación. Solucione estos problemas corrigiendo este cálculo de desplazamiento de bytes en la página.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige el índice de matriz fuera de los límites en dcn35_clkmgr [Por qué] Existe una posible infracción de acceso a la memoria al iterar a través de una matriz de clks dcn35. [Cómo] Limitar la iteración por tamaño de matriz.

*** Pendiente de traducción *** Rejected reason: **REJECT** Duplicate of CVE-2023-46784. Please refer to CVE-2023-46784.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: previene el interbloqueo cambiando j1939_socks_lock a rwlock Los siguientes 3 bloqueos competirían entre sí, causando la situación de interbloqueo en el informe de error de Syzbot: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A Una solución razonable es cambiar j1939_socks_lock por un rwlock, ya que en las raras situaciones en las que se requiere un bloqueo de escritura para la lista vinculada que j1939_socks_lock está protegiendo, el código no intenta adquirir más bloqueos. Esto rompería la dependencia del bloqueo circular, donde, por ejemplo, el subproceso actual ya bloquea j1939_socks_lock e intenta adquirir sk_session_queue_lock y, al mismo tiempo, otro subproceso intenta adquirir j1939_socks_lock mientras mantiene sk_session_queue_lock. NOTA: Este parche no soluciona el error unregister_netdevice informado por Syzbot; en cambio, resuelve una situación de punto muerto para prepararse para uno o más parches adicionales para corregir el error Syzbot, que parece ser un problema de conteo de referencias dentro del código base j1939. [mkl: eliminar cambio de nueva línea no relacionado]