Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: inodo libre cuando ocfs2_get_init_inode() falla syzbot informa inodos ocupados después del desmontaje, para el commit 9c89fe0af826 ("ocfs2: Error de gestión de dquot_initialize()") olvidó llamar a iput() cuando new_inode() tuvo éxito y dquot_initialize() falló.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-tcp: corrige la fuga de memoria cuando falla la creación de un nuevo control Ahora, aunque falla la creación de un nuevo control, no hemos liberado el conjunto de etiquetas ocupado por admin_q, aquí intentamos solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp_bpf: Arreglar la lógica sk_mem_uncharge en tcp_bpf_sendmsg La lógica actual de contabilidad de memoria sk en __SK_REDIRECT está pre-descargando bytes tosend, que es msg->sg.size o un valor menor apply_bytes. Los problemas potenciales con esta estrategia son los siguientes: - Si los bytes enviados reales son más pequeños que tosend, necesitamos cargar algunos bytes de vuelta, como en la línea 487, lo cual está bien pero no parece limpio. - Cuando tosend está configurado en apply_bytes, como en la línea 417, y (ret < 0), podemos perder la descarga de (msg->sg.size - apply_bytes) bytes. [...] 415 tosend = msg->sg.size; 416 si (psock->aplicar_bytes && psock->aplicar_bytes < para enviar) 417 para enviar = psock->aplicar_bytes; [...] 443 sk_msg_return(sk, msg, para enviar); 444 release_sock(sk); 446 tamaño original = msg->sg.tamaño; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, para enviar, indicadores); 449 enviado = tamaño original - msg->sg.tamaño; [...] 454 bloqueo_sock(sk); 455 si (improbable(ret < 0)) { 456 int libre = sk_msg_libre_sincarga(sk, msg); 458 si (!corcho) 459 *copiado -= libre; 460 } [...] 487 si (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - enviado); [...] Al ejecutar la prueba automática test_txmsg_redir_wait_sndmem con txmsg_apply, se informará la siguiente advertencia: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 6 PID: 57 en net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Módulos vinculados: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 No contaminado 6.12.0-rc1.bm.1-amd64+ #43 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Cola de trabajo: eventos sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: muerto000000000100 FS: 000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 proceso_trabajos_programados+0xa3/0x3e0 subproceso_trabajador+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_de_bifurcación+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ fin del seguimiento 000000000000000 ]--- En __SK_REDIRECT, una forma más concisa es retrasar la descarga después de que se finalizan los bytes enviados y descargar este valor. Cuando (ret < 0), invocaremos sk_msg_free. Lo mismo sucede en el caso __SK_DROP, cuando tosend se establece en apply_bytes, podemos perder la descarga de (msg->sg.size - apply_bytes) bytes. La misma advertencia se informará en la autoprueba. [...] 468 caso __SK_DROP: 469 predeterminado: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...] Entonces, en lugar de sk_msg_free_partial, podemos hacer sk_msg_free aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cacheinfo: Asignar memoria durante la conexión en caliente de la CPU si no se hace desde la CPU principal. el commit 5944ce092b97 ("arch_topology: Generar cacheinfo desde la CPU principal") añade una funcionalidad que las arquitecturas pueden utilizar para asignar y generar opcionalmente cacheinfo de forma temprana durante el arranque. el commit 6539cffa9495 ("cacheinfo: Añadir inicializador de nivel temprano específico de la arquitectura") permite que las CPU secundarias corrijan (y reasignen memoria) los datos de cacheinfo si es necesario. Si no se utiliza la funcionalidad de generación temprana y cacheinfo no necesita corrección, nunca se asigna memoria para cacheinfo. x86 no utiliza la funcionalidad de generación temprana. En consecuencia, durante la devolución de llamada hotplug de CPU de cacheinfo, last_level_cache_is_valid() intenta desreferenciar un puntero NULL: BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: last_level_cache_is_valid+0x95/0xe0a Asigne memoria para cacheinfo durante la devolución de llamada hotplug de CPU de cacheinfo si no se hizo antes. Además, antes de determinar la validez de la información de caché de último nivel, asegúrese de que se haya asignado. No basta con comprobar si hay cache_leaves() distintos de cero, ya que algunas arquitecturas (por ejemplo, los procesadores Intel) tienen cache_leaves() distintos de cero antes de la asignación. La anulación de referencias a cacheinfo NULL puede ocurrir en update_per_cpu_data_slice_size(). Esta función itera sobre todas las CPU en línea. Sin embargo, es posible que una CPU se haya conectado recientemente, pero que su cacheinfo aún no se haya asignado. Mientras esté aquí, elimine una sangría innecesaria en allocate_cache_info(). [ bp: Masaje. ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pmdomain: imx: gpcv2: Ajuste del retraso después del protocolo de enlace de encendido El udelay(5) no es suficiente, a veces el pánico del kernel aún se puede activar: [ 4.012973] Pánico del kernel: no sincroniza: Interrupción de error asincrónica [ 4.012976] CPU: 2 UID: 0 PID: 186 Comm: (udev-worker) No contaminado 6.12.0-rc2-0.0.0-devel-00004-g8b1b79e88956 #1 [ 4.012982] Nombre del hardware: Toradex Verdin iMX8M Plus WB en placa Dahlia (DT) [ 4.012985] Rastreo de llamadas: [...] [ 4.013029] arm64_serror_panic+0x64/0x70 [ 4.013034] do_serror+0x3c/0x70 [ 4.013039] el1h_64_error_handler+0x30/0x54 [ 4.013046] el1h_64_error+0x64/0x68 [ 4.013050] clk_imx8mp_audiomix_runtime_resume+0x38/0x48 [ 4.013059] __genpd_runtime_resume+0x30/0x80 [ 4.013066] genpd_runtime_resume+0x114/0x29c [ 4.013073] __rpm_callback+0x48/0x1e0 [ 4.013079] rpm_callback+0x68/0x80 [ 4.013084] rpm_resume+0x3bc/0x6a0 [ 4.013089] __pm_runtime_resume+0x50/0x9c [ 4.013095] pm_runtime_get_suppliers+0x60/0x8c [ 4.013101] __driver_probe_device+0x4c/0x14c [ 4.013108] driver_probe_device+0x3c/0x120 [ 4.013114] __driver_attach+0xc4/0x200 [ 4.013119] bus_for_each_dev+0x7c/0xe0 [ 4.013125] driver_attach+0x24/0x30 [ 4.013130] bus_add_driver+0x110/0x240 [ 4.013135] driver_register+0x68/0x124 [ 4.013142] __platform_driver_register+0x24/0x30 [ 4.013149] sdma_driver_init+0x20/0x1000 [imx_sdma] [ 4.013163] do_one_initcall+0x60/0x1e0 [ 4.013168] do_init_module+0x5c/0x21c [ 4.013175] load_module+0x1a98/0x205c [ 4.013181] init_module_from_file+0x88/0xd4 [ 4.013187] __arm64_sys_finit_module+0x258/0x350 [ 4.013194] anybody_syscall.constprop.0+0x50/0xe0 [ 4.013202] anyone_syscall.constprop.0+0x50/0xe0 [ 4.013202] anyone_syscall.constprop.0+0x50/0xe0 [ 4.013208] anyone_syscall.constprop.0+0x3c/0x140 [ 4.013215] anyone_sysvc+0x120/0x12c [ 4.013222] anyone_sysvc+0x3c/0x140 [ 4.013215] anyone_sysvc+0x120/0x12c [ 4.013222] anyone_sys_sync+0x190/0x194 [ 4.013228] SMP: deteniendo CPUs secundarias La forma correcta es esperar el protocolo de enlace, pero necesita que el reloj BUS de BLK-CTL esté habilitado, lo cual está en un controlador separado. Entonces, el retraso es la única opción aquí. Udelay(10) es un dato obtenido mediante experimento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: qcom: Solo libera MSI de plataforma cuando ESI está habilitado De lo contrario, resultará en una desreferencia de puntero NULL como se muestra a continuación: No se puede gestionar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000008 Rastreo de llamadas: mutex_lock+0xc/0x54 platform_device_msi_free_irqs_all+0x14/0x20 ufs_qcom_remove+0x34/0x48 [ufs_qcom] platform_remove+0x28/0x44 device_remove+0x4c/0x80 device_release_driver_internal+0xd8/0x178 driver_detach+0x50/0x9c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 ufs_qcom_pltform_exit+0x18/0xb94 [ufs_qcom] __arm64_sys_delete_module+0x180/0x260 invocar_llamada_al_sistema+0x44/0x100 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xdc el0t_64_sync_handler+0xc0/0xc4 el0t_64_sync+0x190/0x194

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Cancelar el trabajo de RTC durante ufshcd_remove() Actualmente, el trabajo de RTC solo se cancela durante __ufshcd_wl_suspend(). Cuando se elimina ufshcd en ufshcd_remove(), el trabajo de RTC no se cancela. Debido a esto, cualquier activación adicional del trabajo de RTC después de ufshcd_remove() daría como resultado una desreferencia de puntero NULL como se muestra a continuación: No se puede gestionar la desreferencia de puntero NULL del núcleo en la dirección virtual 00000000000002a4 Cola de trabajo: eventos ufshcd_rtc_work Rastreo de llamadas: _raw_spin_lock_irqsave+0x34/0x8c pm_runtime_get_if_active+0x24/0xb4 ufshcd_rtc_work+0x124/0x19c process_scheduled_works+0x18c/0x2d8 worker_thread+0x144/0x280 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Dado que el trabajo de RTC accede a las estructuras internas de ufshcd, se debe cancelar cuando se elimina ufshcd. Haga esto en ufshcd_remove(), según el orden en ufshcd_init().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommufd: Arreglar out_fput en iommufd_fault_alloc() Como fput() llama a la operación file->f_op->release, donde se liberan los objetos de falla y ictx, no hay necesidad de liberar estos dos después de fput() una vez más, lo que daría como resultado recuentos de referencias desequilibrados: refcount_t: el decremento llega a 0; pérdida de memoria. ADVERTENCIA: CPU: 48 PID: 2369 en lib/refcount.c:31 refcount_warn_saturate+0x60/0x230 Rastreo de llamadas: refcount_warn_saturate+0x60/0x230 (P) refcount_warn_saturate+0x60/0x230 (L) iommufd_fault_fops_release+0x9c/0xe0 [iommufd] ... VFS: Cerrar: el recuento de archivos es 0 (f_op=iommufd_fops [iommufd]) ADVERTENCIA: CPU: 48 PID: 2369 en fs/open.c:1507 filp_flush+0x3c/0xf0 Rastreo de llamadas: filp_flush+0x3c/0xf0 (P) filp_flush+0x3c/0xf0 (L) __arm64_sys_close+0x34/0x98 ... desequilibrado en el recuento de referencias de archivo ADVERTENCIA: CPU: 48 PID: 2369 en fs/file.c:74 __file_ref_put+0x100/0x138 Rastreo de llamadas: __file_ref_put+0x100/0x138 (P) __file_ref_put+0x100/0x138 (L) __fput_sync+0x4c/0xd0 Omita esas dos líneas para corregir las advertencias anteriores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: arregla las escrituras OOB de devmap al eliminar elementos Jordy informó un problema contra XSKMAP que también se aplica a DEVMAP: el índice utilizado para acceder a la entrada del mapa, debido a que es un entero con signo, provoca las escrituras OOB. La solución es tan simple como cambiar el tipo de int a u32, sin embargo, en comparación con el caso de XSKMAP, hay que abordar una cosa más. Cuando el mapa se libera del sistema a través de dev_map_free(), iteramos a través de todas las entradas y una variable de iterador también es un int, lo que implica accesos OOB. Nuevamente, cámbielo a u32. Ejemplo de splat a continuación: [ 160.724676] ERROR: no se puede gestionar el error de página para la dirección: ffffc8fc2c001000 [ 160.731662] #PF: acceso de lectura del supervisor en modo kernel [ 160.736876] #PF: error_code(0x0000) - página no presente [ 160.742095] PGD 0 P4D 0 [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 No contaminado 6.12.0-rc1+ #487 [ 160.757050] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 19/03/2019 [ 160.767642] Cola de trabajo: events_unbound bpf_map_free_deferred [ 160.773308] RIP: 0010:dev_map_free+0x77/0x170 [ 160.777735] Código: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 00000000000000024 [ 160.809331] RDX: 0000000000000000 RSI: 00000000000000024 RDI: ffffc9002c001000 [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [ 160.823823] R10: 000000000000001 R11: 00000000000ee6b2 R12: muerto000000000122 [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [ 160.859604] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.874092] PKRU: 55555554 [ 160.876847] Rastreo de llamadas: [ 160.879338] [ 160.881477] ? __die+0x20/0x60 [ 160.884586] ? exc_page_fault+0xa9/0x140 [ 160.900973] ? asm_exc_page_fault+0x22/0x30 [ 160.905232] ? dev_map_free+0x77/0x170 [ 160.909043] ? dev_map_free+0x58/0x170 [ 160.912857] bpf_map_free_deferred+0x51/0x90 [ 160.917196] process_one_work+0x142/0x370 [ 160.921272] subproceso_trabajador+0x29e/0x3b0 [ 160.925082] ? subproceso_rescatador+0x4b0/0x4b0 [ 160.929157] kthread+0xd4/0x110 [ 160.932355] ? kthread_park+0x80/0x80 [ 160.936079] ret_from_fork+0x2d/0x50 [ 160.943396] ? kthread_park+0x80/0x80 [ 160.950803] ret_desde_fork_asm+0x11/0x20 [ 160.958482]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/dp_mst: Corregir la comprobación de longitud del cuerpo del mensaje de banda lateral MST Corrige la comprobación de longitud del cuerpo del mensaje de banda lateral MST, que debe ser de al menos 1 byte teniendo en cuenta el CRC del cuerpo del mensaje (también conocido como CRC de los datos del mensaje) al final del mensaje. Esto corrige un caso en el que un dispositivo de rama MST devuelve un encabezado con un CRC de encabezado correcto (que indica una longitud de cuerpo recibida correctamente), con la longitud del cuerpo configurada incorrectamente en 0. Esto luego provocará una corrupción de memoria en drm_dp_sideband_append_payload() y los siguientes errores en dmesg: UBSAN: array-index-out-of-bounds en drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Seguimiento de llamadas: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: se detectó una escritura que abarca el campo (tamaño 18446744073709551615) de un solo campo "&msg->msg[msg->curlen]" en drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (tamaño 256) Seguimiento de llamadas: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: se corrige un posible acceso a memoria fuera de los límites en nilfs_find_entry() Syzbot informó que al buscar registros en un directorio donde el i_size del inodo está dañado y tiene un valor grande, puede ocurrir un acceso a memoria fuera del rango de folio/página, o puede detectarse un error de use-after-free si KASAN está habilitado. Esto se debe a que nilfs_last_byte(), que es llamado por nilfs_find_entry() y otros para calcular la cantidad de bytes válidos de datos de directorio en una página a partir de i_size y el índice de página, pierde los 32 bits superiores de la información de tamaño de 64 bits debido a un tipo inadecuado de variable local a la que se asigna el valor de i_size. Esto causó un valor de desplazamiento de bytes grande debido al desbordamiento en el cálculo de la dirección final en la llamada nilfs_find_entry(), lo que resultó en un acceso a memoria que excede el tamaño de folio/página. Solucione este problema cambiando el tipo de la variable local que causa la pérdida de bits de "unsigned int" a "u64". El valor de retorno de nilfs_last_byte() también es del tipo "unsigned int", pero se trunca para no superar PAGE_SIZE y no se produce ninguna pérdida de bits, por lo que no se requiere ningún cambio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: sysfs: Evitar división por cero Evita una división por 0 cuando la monitorización no está habilitada.