Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: corregir un bloqueo en __device_attach En la función __device_attach, la lógica de retención de bloqueo es la siguiente: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) Como se muestra arriba, cuando se permite hacer sondeos asincrónicos, debido a falta de memoria o límite de trabajo, no se permite el trabajo asincrónico, para hacer la ejecución sincrónica en su lugar. conducirá a un interbloqueo AA debido a que __device_attach_async_helper obtiene el bloqueo dev. Para solucionar el interbloqueo, mueva async_schedule_dev fuera de device_lock, como podemos ver, en async_schedule_node_domain, el parámetro de queue_work_node es system_unbound_wq, por lo que puede aceptar operaciones simultáneas. lo que tampoco cambiará la lógica del código y no conducirá a un interbloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: tcp_rtx_synack() puede ser llamado desde el contexto del proceso Laurent reportó el informe adjunto [1] Este error se activa con las siguientes condiciones: 0) Kernel construido con CONFIG_DEBUG_PREEMPT=y 1) Se crea un nuevo socket TCP FastOpen pasivo. Este socket FO espera un ACK proveniente del cliente para ser un ACK ESTABLISHED completo. 2) Una operación de socket en este socket pasa por el baile lock_sock() release_sock(). 3) Mientras el socket es propiedad del usuario en el paso 2), se recibe una retransmisión del SYN y se almacena en el backlog del socket. 4) En el momento release_sock(), el backlog del socket se procesa mientras está en el contexto del proceso. 5) Se cocina un paquete SYNACK en respuesta a la retransmisión de SYN. 6) -> tcp_rtx_synack() se llama en el contexto del proceso. Antes de el commit con culpa, tcp_rtx_synack() siempre se llamaba desde el controlador BH, desde un controlador de temporizador. Corrija esto usando TCP_INC_STATS() y NET_INC_STATS() que no asumen que el llamador está en un contexto no preemptible. [1] BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180 caller is tcp_rtx_synack.part.0+0x36/0xc0 CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1 Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021 Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: ts4800_wdt: Se corrige la pérdida de recuento de referencias en ts4800_wdt_probe of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado; cuando termine, debemos usar of_node_put() en él. Se agrega of_node_put() faltante en algunas rutas de error.

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/papr_scm: no solicita estadísticas con un búfer de estadísticas de tamaño '0' Sachin informó [1] que en un LPAR POWER-10 está viendo un pánico del kernel que se informa con vPMEM cuando se llama a la sonda papr_scm. El pánico tiene el formato siguiente y se observa solo con la siguiente opción deshabilitada (perfil) para dicho LPAR 'Habilitar recopilación de información de rendimiento' en la HMC: El kernel intentó escribir la página del usuario (1c): ¿intento de explotación? (uid: 0) ERROR: Desreferencia de puntero NULL del kernel al escribir en 0x0000001c Dirección de instrucción con error: 0xc008000001b90844 Oops: Acceso del kernel al área defectuosa, sig: 11 [#1] NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm] LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm] Seguimiento de llamadas: 0xc00000000941bca0 (no confiable) papr_scm_probe+0x2ac/0x6ec [papr_scm] platform_probe+0x98/0x150 really_probe+0xfc/0x510 __driver_probe_device+0x17c/0x230 ---[ fin del seguimiento 0000000000000000 ]--- Pánico del kernel: no se sincroniza: excepción fatal En la investigación, parece que este pánico se produjo debido a que se proporcionó un 'stat_buffer' de tamaño==0 a drc_pmem_query_stats() para obtener todos los identificadores de estadísticas de rendimiento de un NVDIMM. Sin embargo, no se debería haber llamado a drc_pmem_query_stats() ya que el NVDIMM vPMEM no admite ningún identificador de estadísticas de rendimiento. Esto se produjo debido a la falta de verificación de 'p->stat_buffer_len' al comienzo de papr_scm_pmu_check_events(), lo que indica que el NVDIMM no admite estadísticas de rendimiento. Solucione este problema introduciendo la comprobación de 'p->stat_buffer_len' al comienzo de papr_scm_pmu_check_events(). [1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_octeon_cf: se corrige la pérdida de recuento de referencias en octeon_cf_probe. La referencia que toma la función de _find_device_by_node() se debe liberar cuando ya no se necesite. Se agrega la función put_device() que falta para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Trampa desbordamientos de segmentos RDMA Impide que svc_rdma_build_writes() se aleje del final de la matriz de segmentos de un fragmento de escritura. Detectado con KASAN. La prueba que esta corrección reemplaza no es válida y podría haber quedado de un prototipo anterior del trabajo de PCL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi: No importar certificados desde UEFI Secure Boot para Mac T2 En Mac T2 de Apple, cuando Linux intenta leer las variables efi db y dbx en el arranque temprano para cargar certificados UEFI Secure Boot, se produce un error de página en el código de firmware de Apple y los servicios de tiempo de ejecución de EFI se desactivan con los siguientes registros: [Error de firmware]: Error de página causado por el firmware en PA: 0xffffb1edc0068000 ADVERTENCIA: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 De esta forma evitamos leer estas variables UEFI y, por lo tanto, evitamos el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: regla de flujo de memleak de la ruta de confirmación. La ruta de cancelación libera el objeto de regla de flujo, pero la ruta de confirmación no lo hace. Actualice el código para destruir estos objetos antes de liberar la transacción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panfrost: El trabajo debe hacer referencia a MMU, no a file_priv Desde hace un tiempo se ha permitido que un contexto MMU sobreviva a su panfrost_priv correspondiente, sin embargo, la estructura del trabajo aún hace referencia a panfrost_priv para obtener el contexto MMU. Si panfrost_priv se ha liberado, se trata de un use-after-free que he podido activar, lo que ha dado como resultado un splat. Para solucionar esto, elimine la referencia a panfrost_priv en la estructura del trabajo y agregue una referencia directa a la estructura MMU, que es lo que realmente se necesita.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en total_data_blocks Como informó Yanming en Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215916 El mensaje del kernel se muestra a continuación: ¡ERROR del kernel en fs/f2fs/segment.c:2560! Call Trace: allocate_segment_by_default+0x228/0x440 f2fs_allocate_data_block+0x13d1/0x31f0 do_write_page+0x18d/0x710 f2fs_outplace_write_data+0x151/0x250 f2fs_do_write_data_page+0xef9/0x1980 move_data_page+0x6af/0xbc0 do_garbage_collect+0x312f/0x46f0 f2fs_gc+0x6b0/0x3bc0 f2fs_balance_fs+0x921/0x2260 f2fs_write_single_data_page+0x16be/0x2370 f2fs_write_cache_pages+0x428/0xd00 f2fs_write_data_pages+0x96e/0xd50 do_writepages+0x168/0x550 __writeback_single_inode+0x9f/0x870 writeback_sb_inodes+0x47d/0xb20 __writeback_inodes_wb+0xb2/0x200 wb_writeback+0x4bd/0x660 wb_workfn+0x5f3/0xab0 process_one_work+0x79f/0x13e0 worker_thread+0x89/0xf60 kthread+0x26a/0x300 ret_from_fork+0x22/0x30 RIP: 0010:new_curseg+0xe8d/0x15f0 La causa raíz es: ckpt.valid_block_count es inconsistente con la tabla SIT, la información estadística indica que el sistema de archivos tiene bloques libres, pero la tabla SIT indica que el sistema de archivos no tiene segmentos libres. Por lo tanto, durante la recolección de basura, se genera un pánico cuando el asignador LFS no encuentra un segmento libre. Este parche intenta solucionar este problema al verificar la coherencia entre ckpt.valid_block_count y el bloque contabilizado desde SIT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura para el inodo en línea Yanming informó de un error del kernel en el kernel de Bugzilla [1], que se puede reproducir. El mensaje del error es: El mensaje del kernel se muestra a continuación: kernel BUG at fs/inode.c:611! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 dput+0x2dd/0x720 do_renameat2+0x596/0x970 __x64_sys_rename+0x78/0x90 do_syscall_64+0x3b/0x90 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895 El error se debe a que el inodo fuzzed tiene indicadores inline_data y cifrados. Durante f2fs_evict_inode(), como el inodo fue eliminado por rename(), esto provocará una conversión de datos en línea debido a indicadores conflictivos. La caché de la página se contaminará y se activará el pánico en clear_inode(). Intente corregir el error realizando más comprobaciones de integridad para el inodo de datos en línea en sanity_check_inode().