Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: corrige el manejo de errores de TX CQE Para un tipo de error de TX CQE desconocido (probablemente de un hardware más nuevo), aún libere el SKB, actualice la cola de cola, etc.; de lo contrario, la contabilidad estará equivocada. Además, los errores de TX pueden desencadenarse al inyectar paquetes corruptos, así que reemplace WARN_ONCE para registrar errores con velocidad limitada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/vt-d: evitar la asignación de memoria en iommu_suspend() La devolución de llamada de suspensión de syscore iommu_suspend() se invoca con IRQ deshabilitado. La asignación de memoria con el indicador GFP_KERNEL puede volver a habilitar las IRQ durante la devolución de llamada de suspensión, lo que puede causar problemas intermitentes de suspensión/hibernación con los siguientes seguimientos del kernel: Llamando a iommu_suspend+0x0/0x1d0 ------------[ cut aquí ]------------ ADVERTENCIA: CPU: 0 PID: 15 en kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 ... CPU: 0 PID: 15 Comm: rcu_preempt Contaminado : GUE 6.3-intel #r1 RIP: 0010:ktime_get+0x9b/0xb0 ... Seguimiento de llamadas: tick_sched_timer+0x22/0x90 ? __pfx_tick_sched_timer+0x10/0x10 __hrtimer_run_queues+0x111/0x2b0 hrtimer_interrupt+0xfa/0x230 __sysvec_apic_timer_interrupt+0x63/0x140 sysvec_apic_timer_interrupt+0x7b/0xa0 asm _sysvec_apic_timer_interrupt+0x1f/0x30 ... ---------- --[ cortar aquí ]------------ Interrupciones habilitadas después de iommu_suspend+0x0/0x1d0 ADVERTENCIA: CPU: 0 PID: 27420 en drivers/base/syscore.c:68 syscore_suspend+0x147/0x270 CPU : 0 PID: 27420 Comunicaciones: rtcwake Contaminado: GUWE 6.3-intel #r1 RIP: 0010:syscore_suspend+0x147/0x270 ... Seguimiento de llamadas: hibernation_snapshot+0x25b/0x670 hibernate+0xcd/0x390 state_store+0xcf/0xe0 kobj_attr _tienda +0x13/0x30 sysfs_kf_write+0x3f/0x50 kernfs_fop_write_iter+0x128/0x200 vfs_write+0x1fd/0x3c0 ksys_write+0x6f/0xf0 __x64_sys_write+0x1d/0x30 do_syscall_64+0x3b/0 x90 Entry_SYSCALL_64_after_hwframe+0x72/0xdc Dado que sólo se necesitan 4 palabras de memoria, evite el asignación de memoria en iommu_suspend().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/damon/vaddr-test: corrige la pérdida de memoria en damon_do_test_apply_tres_regions() Cuando CONFIG_DAMON_VADDR_KUNIT_TEST=y y se hace CONFIG_DEBUG_KMEMLEAK=y y CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, se detecta la siguiente pérdida de memoria. Desde el commit 9f86d624292c ("mm/damon/vaddr-test: eliminar variables innecesarias"), damon_destroy_ctx() se elimina, pero aún se llama a damon_new_target() y damon_new_region(), la damon_region asignada por kmem_cache_alloc() en damon_new_region() y el damon_target asignado por kmalloc en damon_new_target() no se libera. Y el damon_region que está asignado en damon_new_region() en damon_set_regions() tampoco se libera. Entonces use damon_destroy_target para liberar todos los damon_regions y damon_target. objeto sin referencia 0xffff888107c9a940 (tamaño 64): comm "kunit_try_catch", pid 1069, jiffies 4294670592 (edad 732,761 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b... .........kkkk 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `................. backtrace: [] kmalloc_trace +0x27/0xa0 [] damon_new_target+0x3f/0x1b0 [] damon_do_test_apply_tres_regiones.constprop.0+0x95/0x3e0 [] damon_test_apply_tres_regiones1+0x21e/ 0x260 [] kunit_generic_run_threadfn_adapter+0x4a/0x90 [< ffffffff81237cf6>] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [] ret_from_fork_asm+0x11/0x20 objeto sin referencia 0xffff8881079cc740 (tamaño 56): comm "kunit_try_catch", pid 1069, santiamén 4294670592 (edad 732,761 s ) volcado hexadecimal (primeros 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk retroceso: [] damon_new_region+0x22/0x1c0 [] damon_do_test_apply_tres_regiones.constprop.0+0xd1/0x3e0 [] damon_test_apply_tres_regiones1+0x21e/0x260 [ ] kunit_generic_run_threadfn_adapter+0x4a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [] ret_from_ fork_asm+0x11/0x20 objeto sin referencia 0xffff888107c9ac40 (tamaño 64): comm "kunit_try_catch ", pid 1071, santiamén 4294670595 (edad 732,843 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........xv.... rastreo: [] kmalloc_trace+0x27/0xa0 [] damon_new_target+0x3f/0x1b0 [] damon_do_test_apply_tres_regiones.constprop.0+0x95/0x3e0 [] damon_test_apply_tres_regiones2+0x21e/0x260 [] kunit_generic_run_threadfn_adapter+0x4 a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork +0x2d/0x70 [] ret_from_fork_asm+0x11/0x20 objeto sin referencia 0xffff8881079ccc80 (tamaño 56): comm "kunit_try_catch", pid 1071, jiffies 4294670595 (edad 732.843 s) volcado hexadecimal (primero 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk retroceso : [] damon_new_region+0x22/0x1c0 [] damon_do_test_apply_tres_regiones.constprop.0+0xd1/0x3e0 [] damon_test_apply_tres_regiones2+0x21e/0x260 [] kunit_generic_run_threadfn_adapter+0x4a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: dts: qcom: sdm845-db845c: marcar la región de memoria de inicio continua como reservada Agregar una región de memoria reservada para la memoria framebuffer (la región de memoria de inicio configurada por el gestor de arranque). Soluciona un problema de pánico en el kernel (arm-smmu: fallo de contexto no controlado en esta región de memoria en particular) informado en DB845c que ejecuta v5.10.y.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab_common: corrige la corrupción de la lista slab_caches después de kmem_cache_destroy() Después de el commit en Correcciones:, si un módulo que creó un caché de losa no libera todos sus objetos asignados antes de destruir el cache (en el momento rmmod), podríamos terminar liberando el objeto kmem_cache sin eliminarlo de la lista slab_caches, corrompiendo así la lista ya que kmem_cache_destroy() ignora el valor de retorno de Shutdown_cache(), que a su vez nunca elimina el objeto kmem_cache de slabs_list en caso __kmem_cache_shutdown() no puede liberar todas las losas del caché. Esto es fácilmente observable en un kernel construido con CONFIG_DEBUG_LIST=y ya que después de ese lanzamiento, el sistema activará inmediatamente las aserciones list_add o list_del, similares a la que se muestra a continuación tan pronto como se cree o destruya otro kmem_cache: [ 1041.213632] list_del corrupción. siguiente->anterior debería ser ffff89f596fb5768, pero era 52f1e5016aeee75d. (siguiente=ffff89f595a1b268) [1041.219165] ------------[ cortar aquí ]------------ [ 1041.221517] ¡ERROR del kernel en lib/list_debug.c:62! [ 1041.223452] código de operación no válido: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: cargado Contaminado: GBW OE 6.5.0 #15 [ 1041.228244] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 24/05/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Otra forma rápida de desencadenar este problema, en un kernel con CONFIG_SLUB=y, es configurar slub_debug para envenenar los objetos liberados y luego simplemente ejecutar cat /proc/slabinfo después de eliminar el módulo que filtra los objetos slab, en cuyo caso el kernel entrará en pánico: [50.954843] falla de protección general, probablemente para la dirección no canónica 0xa56b6b6b6b6b6b8b: 0000 [#1 ] PREEMPT SMP PTI [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: cargado Contaminado: GBW OE 6.5.0 #15 [ 50.966808] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS edk2-20230524- 3.fc37 24/05/2023 [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0 Este parche soluciona este problema verificando correctamente el valor de retorno de Shutdown_cache() antes de tomar la rama kmem_cache_release().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/meson: corrige la pérdida de memoria en ->hpd_notify callback El EDID devuelto por drm_bridge_get_edid() debe liberarse.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "tty: n_gsm: fix UAF in gsm_cleanup_mux" Esto revierte el commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239. el commit anterior se revierte porque no resolvió el problema original. gsm_cleanup_mux() intenta liberar los ttys virtuales llamando a gsm_dlci_release() para cada DLCI disponible. Allí, se llama a dlci_put() para disminuir el contador de referencia para el DLCI a través de tty_port_put() que finalmente llama a gsm_dlci_free(). Esto ya borra el puntero que se está verificando en gsm_cleanup_mux() antes de llamar a gsm_dlci_release(). Por lo tanto, no es necesario borrar este puntero en gsm_cleanup_mux() como se hizo en el commit revertida. el commit introduce una desreferencia de puntero nulo: ? __die+0x1f/0x70 ? page_fault_oops+0x156/0x420? search_exception_tables+0x37/0x50? fixup_exception+0x21/0x310? exc_page_fault+0x69/0x150? asm_exc_page_fault+0x26/0x30? tty_port_put+0x19/0xa0 gsmtty_cleanup+0x29/0x80 [n_gsm] release_one_tty+0x37/0xe0 proceso_one_work+0x1e6/0x3e0 trabajador_thread+0x4c/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 El problema real es que nada protege a dlci_put() de ser llamado varias veces mientras el controlador tty se activó pero aún no terminó de llamar a gsm_dlci_free().

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: media: uvcvideo: Fix OOB read Si el índice proporcionado por el usuario es mayor que el tamaño de la máscara, podríamos hacer una lectura fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: soluciona el posible Use After Free de la clave Cuando ieee80211_key_link() es llamado por ieee80211_gtk_rekey_add() pero devuelve 0 debido a la protección KRACK (reinstalación de clave idéntica), ieee80211_gtk_rekey_add() aún devolverá un puntero a la clave, en un posible Use After Free. Esto normalmente no sucede ya que iwlwifi solo lo llama en caso de descarga de recodificación de WoWLAN, que tiene su propia protección KRACK, pero aún es mejor solucionarlo, hágalo devolviendo un código de error y convirtiéndolo en exitoso solo en el límite cfg80211, dejando el error para personas que llaman mal de ieee80211_gtk_rekey_add().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: elimina mensajes de MDS al desmontar. Al desmontar, todos los buffers sucios se vaciarán y, una vez finalizada la última solicitud de osd, se liberará la última referencia de i_count. Luego, eliminará la tapa sucia/se ajustará a los MDS, y el desmontaje no esperará los posibles ataques, lo que retendrá los inodos al actualizar los metadatos localmente, pero esto ya no tiene sentido. Esto hará que evict_inodes() omita estos inodos. Si el cifrado está habilitado, el kernel genera una advertencia al eliminar las claves de cifrado cuando los inodos omitidos aún contienen el llavero: ADVERTENCIA: CPU: 4 PID: 168846 en fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0 CPU: 4 PID : 168846 Comm: desmontaje Contaminado: GS 6.1.0-rc5-ceph-g72ead199864c #1 Nombre del hardware: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 17/12/2015 RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0 RSP : 0018:ffffc9000b277e28 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00 RDX: 0000000080000000 RSI: ffffffff822f 3a09 RDI: ffff888108f59000 RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 00000000000000000 R10: 00000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40 R13: ffff888108f59000 R14: ffff8881d394f800 R15 : 0000000000000000 FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005 0033 CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 00000000000000000 DR 3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: generic_shutdown_super+0x47/0x120 kill_anon_super+0x14/0x30 ceph_kill_sb+0x36/0x90 [ceph] deactivate_locked_super+0x29/0x60 cleanup_mnt+0 xb8/0x140 task_work_run+0x67/0xb0 exit_to_user_mode_prepare+0x23d/0x240 syscall_exit_to_user_mode+0x25/0x60 do_syscall_64+0x40/0x80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd83dc39e9b Más tarde, el kernel fallará cuando iput() los inodos y desreferencia el "sb->s_master_keys", que ha sido liberado por generic_shutdown_super() .

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/47x: Se corrigió la falla de devolución de la llamada al sistema 47x Eddie informó que los kernels más nuevos fallaban durante el arranque en su sistema 476 FSP2: el kernel intentó ejecutar la página del usuario (b7ee2000): ¿intento de explotación? (uid: 0) ERROR: No se puede manejar la recuperación de instrucciones del kernel Dirección de instrucción errónea: 0xb7ee2000 Ups: Acceso al kernel del área defectuosa, firma: 11 [#1] BE PAGE_SIZE=4K FSP-2 Módulos vinculados en: CPU: 0 PID: 61 Comm: mount No contaminado 6.1.55-d23900f.ppcnf-fsp2 #1 Nombre de hardware: ibm,fsp2 476fpe 0x7ff520c0 FSP-2 NIP: b7ee2000 LR: 8c008000 CTR: 00000000 REGS: bffebd83 TRAP: 0400 No contaminado (6.1. 55-d23900f .ppcnf-fs p2) MSR: 00000030 CR: 00001000 XER: 20000000 GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000 GPR08: 00000 033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000 GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0 GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0 NIP [b7ee2000] 0xb7ee2000 LR [8c008000] 0x8c008000 Seguimiento de llamadas: volcado de instrucciones : XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ fin de seguimiento 00000000000000000 ] --- El problema está en ret_from_syscall donde se realiza la verificación de icache_44x_need_flush. Cuando se necesita la descarga, el código salta fuera de línea para realizar la descarga y luego intenta saltar hacia atrás para continuar con el retorno de la llamada al sistema. Sin embargo, la bifurcación de regreso a la etiqueta 1b no regresa a la ubicación correcta, sino que se bifurca justo antes de regresar al espacio de usuario, lo que provoca que el rfi utilice valores de registro falsos. La falla fue introducida por el commit 6f76a01173cc ("powerpc/syscall: implementar lógica de entrada/salida de llamadas al sistema en C para PPC32") que sin darse cuenta eliminó la etiqueta "1" y la reutilizó en otro lugar. Solucionelo agregando etiquetas locales con nombre en las ubicaciones correctas. Tenga en cuenta que la etiqueta de devolución debe estar fuera de ifdef para que CONFIG_PPC_47x=n se compile.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: pm80xx: evite filtrar etiquetas al procesar el comando OPC_INB_SET_CONTROLLER_CONFIG Las etiquetas asignadas para el comando OPC_INB_SET_CONTROLLER_CONFIG deben liberarse cuando recibimos la respuesta.