Vulnerabilidades

Una falla en Thales SafeNet Authentication Client anterior a 10.8 R10 en Windows permite a un atacante ejecutar código a nivel de SYSTEM a través de acceso local.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: corrige use-after-free en tw_timer_handler Se encontró un problema de pánico en el mundo real como se muestra a continuación en Linux 5.4. ERROR: no se puede manejar el error de página para la dirección: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Seguimiento de llamadas: call_timer_fn+0x2b/ 0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/ 0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 Este problema también se informó desde 2017 en el hilo [1], desafortunadamente, el problema aún se puede reproducir después de corregir DCCP. ipv4_mib_exit_net se llama antes de tcp_sk_exit_batch cuando se destruye un espacio de nombres de red, ya que tcp_sk_ops está registrado antes de ipv4_mib_ops, lo que significa que tcp_sk_ops está al frente de ipv4_mib_ops en la lista de pernet_list. Habrá un use-after-free en net->mib.net_statistics en tw_timer_handler después de ipv4_mib_exit_net si hay algunos temporizadores de espera a bordo. Este error no se introduce mediante la confirmación f2bf415cfed7 ("mib: add net to NET_ADD_STATS_BH") ya que net_statistics es una variable global en lugar de una asignación y liberación dinámicas. En realidad, la confirmación 61a7e26028b9 ("mib: poner estadísticas de red en struct net") introduce el error ya que coloca estadísticas de red en struct net y las libera cuando se destruye el espacio de nombres de red. Mover init_ipv4_mibs() al frente de tcp_init() para corregir este error y reemplazar pr_crit() con pánico() ya que continuar no tiene sentido cuando init_ipv4_mibs() falla. [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/dbgfs: corrige las fugas de 'struct pid' en 'dbgfs_target_ids_write()' La interfaz DAMON debugfs aumenta los recuentos de referencias de 'struct pid' para los objetivos de la escritura del archivo 'target_ids' devolución de llamada ('dbgfs_target_ids_write()'), pero disminuye los recuentos solo en la devolución de llamada de terminación de monitoreo de DAMON ('dbgfs_before_terminate()'). Por lo tanto, cuando el archivo 'target_ids' se escribe repetidamente sin que DAMON supervise el inicio/terminación, el recuento de referencias no disminuye y, por lo tanto, no se puede liberar memoria para 'struct pid'. Este commit soluciona este problema al disminuir el recuento de referencias cuando se escribe 'target_ids'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KEYS: de confianza: corrige la reserva de TPM para sellar/dessellar El parche original 8c657a0590de ("KEYS: de confianza: reservar TPM para operaciones de sellar y dessellar") era correcto en la lista de correo: https ://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ Pero de alguna manera se modificó la base para que tpm_try_get_ops() en tpm2_seal_trusted() se perdiera. Esto provoca un desequilibrio en las operaciones de TPM y provoca fallos en el hardware basado en TIS. Esta solución devuelve el tpm_try_get_ops() perdido

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/mount_setattr: limpiar siempre mount_kattr. Asegúrese de que se llame a finish_mount_kattr() después de que mount_kattr se haya compilado con éxito tanto en el caso de éxito como en el de fracaso para evitar que se filtren las referencias que tomamos cuando lo compilamos. Regresamos temprano si falla la búsqueda de ruta, por lo que corremos el riesgo de filtrar una referencia adicional que tomamos al compilar mount_kattr cuando se solicitó un montaje con idmapped.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: st21nfca: corrige la pérdida de memoria en la sonda del dispositivo y elimina 'phy->pending_skb' cuando se asigna la sonda del dispositivo, pero olvidó liberarla en la ruta de manejo de errores y eliminar la ruta, esto causa pérdida de memoria de la siguiente manera: objeto sin referencia 0xffff88800bc06800 (tamaño 512): comunicación "8", pid 11775, santiago 4295159829 (edad 9.032 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................. backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [ <0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2 Solucionarlo liberando 'pending_skb' por error y elimínelo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: soluciona el pánico del kernel causado por la carrera de smc_sock. Se produce un bloqueo cuando smc_cdc_tx_handler() intenta acceder a smc_sock pero smc_release() ya lo ha liberado. [ 4570.695099] ERROR: no se puede manejar el error de página para la dirección: 000000002eae9e88 [ 4570.696048] #PF: acceso de escritura del supervisor en modo kernel [ 4570.696728] #PF: error_code(0x0002) - página no presente [ 4570.697401] PGD 0 P4D 0 [ 4 570.697716 ] Ups: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Nombre de hardware: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/ 0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <...> [ 4570.711446] Seguimiento de llamadas: [ 4570.711746] [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.7 12470] smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521] irq_exit_rcu+0xc4/0x f0 [4570.714934] common_interrupt+0xba/0xe0 Aunque smc_cdc_tx_handler() comprobó la existencia de smc conexión, es posible que smc_release() ya haya descartado y liberado el socket smc antes de que smc_cdc_tx_handler() lo visite más. smc_cdc_tx_handler() |smc_release() si (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- último sock_put, | smc_sock liberó bh_lock_sock(&smc->sk) (pánico) | Para asegurarnos de que no recibiremos ningún mensaje CDC después de liberar el smc_sock, agregue un recuento en smc_connection para el mensaje CDC en vuelo (publicado en el QP pero no haya recibido el CQE relacionado) y no libere el smc_connection hasta que todo Los mensajes CDC a bordo se han realizado, tanto para los exitosos como para los fallidos. El uso de refcount en mensajes CDC trae otro problema: cuando el enlace se va a destruir, smcr_link_clear() restablecerá el QP, lo que luego eliminará todos los CQE pendientes relacionados con el QP en el CQ. Para asegurarse de que todos los CQE siempre regresen para que el recuento en smc_connection siempre pueda llegar a 0, smc_ib_modify_qp_reset() fue reemplazado por smc_ib_modify_qp_error(). Y elimine el tiempo de espera en smc_wr_tx_wait_no_pending_sends() ya que debemos esperar a que se completen todos los WQE pendientes, o podemos encontrarnos con use-after- free al manejar CQE. Para la rutina de eliminación del dispositivo IB, debemos esperar a que se destruyan todos los QP de ese dispositivo antes de poder destruir los CQ del dispositivo, o el recuento de referencia en smc_connection no llegará a 0 y smc_sock no podrá liberarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: intel-sdw-acpi: reforzar la detección del controlador El código existente actualmente establece un puntero a un identificador ACPI antes de verificar que en realidad es un controlador SoundWire. Esto puede provocar problemas en los que el recorrido del gráfico continúa y finalmente falla, pero el puntero ya estaba configurado. Este parche cambia la lógica para que la información proporcionada a la persona que llama se establezca cuando se encuentra un controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nitro_enclaves: use la llamada get_user_pages_unlocked() para manejar mmap afirmar. Después del commit 5b78ed24e8ec ("mm/pagemap: agregue anotaciones mmap_assert_locked() a find_vma*()"), la llamada a get_user_pages( ) activará la afirmación mmap. estático en línea void mmap_assert_locked(struct mm_struct *mm) { lockdep_assert_held(&mm->mmap_lock); VM_BUG_ON_MM(!rwsem_is_locked(&mm->mmap_lock), mm); } [62.521410] ¡ERROR del kernel en include/linux/mmap_lock.h:156! ................................................. ......... [ 62.538938] RIP: 0010:find_vma+0x32/0x80 ................................. ................................. [ 62.605889] Seguimiento de llamadas: [ 62.608502] [ 62.610956] ? LOCK_TIMER_BASE+0x61/0x80 [62.614106] find_extend_vma+0x19/0x80 [62.617195] __get_user_pages+0x9b/0x6a0 [62.6203356] __guup_longter_locked+0x42d/0x450 [62.620356] terminar_esperar+0x41/0x80 [62.626748]? __kmalloc+0x178/0x2f0 [ 62.629768] ne_set_user_memory_region_ioctl.isra.0+0x225/0x6a0 [nitro_enclaves] [ 62.635776] ne_enclave_ioctl+0x1cf/0x6d7 [nitro_enclaves] [ 62.639541] __x64 _sys_ioctl+0x82/0xb0 [ 62.642620] do_syscall_64+0x3b/0x90 [ 62.645642] Entry_SYSCALL_64_after_hwframe+0x44/0xae Utilice get_user_pages_unlocked() al configurar las regiones de memoria del enclave. Es un patrón similar al mmap_read_lock() usado junto con get_user_pages().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: parisc: borra el valor IIR obsoleto en la trampa de derechos de acceso a instrucciones Cuando ocurre una trampa 7 (derechos de acceso a instrucciones), esto significa que la CPU no pudo ejecutar una instrucción debido a que faltan permisos de ejecución en la región de la memoria. En este caso, parece que la CPU ni siquiera obtuvo la instrucción de la memoria y, por lo tanto, no la almacenó en el registro cr19 (IIR) antes de llamar al controlador de trampas. Entonces, el manejador de trampas encontrará algún valor obsoleto aleatorio en cr19. Este parche simplemente sobrescribe el valor IIR obsoleto con un valor mágico constante de "mala comida" (0xbaadf00d), con la esperanza de que la gente no empiece a intentar comprender los diversos valores IIR aleatorios en los volcados de la trampa 7.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sctp: use call_rcu para liberar el endpoint. Este parche tiene como objetivo retrasar la liberación del endpoint llamando a call_rcu() para solucionar otro problema de use-after-free en sctp_sock_dump(): ERROR: KASAN: use-after-free en __lock_acquire+0x36d9/0x4c20 Rastreo de llamadas: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h :135 [en línea] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [en línea] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/ 0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [en línea] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c: 5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x6 06/0x1080 neto/ netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [en línea] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cm re neto /core/sock_diag.c:232 [en línea] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag. c:274 Este problema ocurre cuando se quita asoc y se libera el sk antiguo después de obtenerlo mediante asoc->base.sk y antes de llamar a lock_sock(sk). Para evitar que sk se libere, como titular de sk, ep debe estar activo al llamar a lock_sock(). Este parche usa call_rcu() y mueve sock_put y ep free a sctp_endpoint_destroy_rcu(), por lo que es seguro intentar mantener el ep bajo rcu_read_lock en sctp_transport_traverse_process(). Si sctp_endpoint_hold() devuelve verdadero, significa que este ep todavía está vivo, lo hemos retenido y podemos continuar descartándolo; Si devuelve falso, significa que este ep está muerto y puede liberarse después de rcu_read_unlock, y debemos omitirlo. En sctp_sock_dump(), después de bloquear el sk, si este ep es diferente de tsp->asoc->ep, significa que durante este volcado, este asoc se eliminó antes de llamar a lock_sock(), y el sk debe omitirse; Si este ep es el mismo con tsp->asoc->ep, significa que no se produce ningún despegue en este asoc y, debido a lock_sock, tampoco se producirá ningún despegue hasta que se libere_sock. Tenga en cuenta que retrasar la liberación del endpoint no retrasará la liberación del puerto, ya que la liberación del puerto ocurre en sctp_endpoint_destroy() antes de llamar a call_rcu(). Además, liberar el endpoint mediante call_rcu() hace que sea seguro acceder a sk mediante asoc->base.sk en sctp_assocs_seq_show() y sctp_rcv(). Gracias Jones por plantear este problema. v1->v2: - mejorar el registro de cambios. - agregue kfree(ep) a sctp_endpoint_destroy_rcu(), como notó Jakub.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: mtu3: corrección de advertencia de verificación de list_head Esto se debe a la desinicialización de list_head. ERROR: KASAN: uso después de la liberación en __list_del_entry_valid+0x34/0xe4 Rastreo de llamadas: dump_backtrace+0x0/0x298 show_stack+0x24/0x34 dump_stack+0x130/0x1a8 print_address_description+0x88/0x56c __kasan_report+0x1b8/0x2a0 kasan_report +0x14/0x20 __asan_load8+ 0x9c/0xa0 __list_del_entry_valid+0x34/0xe4 mtu3_req_complete+0x4c/0x300 [mtu3] mtu3_gadget_stop+0x168/0x448 [mtu3] usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4