Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: max9759: corrige el desbordamiento en altavoz_gain_control_put() Compruebe si hay valores negativos de "priv->gain" para evitar un acceso fuera de los límites. La preocupación es que estos puedan provenir del usuario a través de: -> snd_ctl_elem_write_user() -> snd_ctl_elem_write() -> kctl->put()

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm: mxsfb: corrige la desreferencia del puntero NULL. mxsfb nunca debería desreferenciar el puntero NULL que drm_atomic_get_new_bridge_state puede devolver. En su lugar, asuma un formato fijo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net, neigh: no activar sondas inmediatas en NUD_FAILED desde neigh_managed_work syzkaller pudo activar un punto muerto para las entradas NTF_MANAGED [0]: kworker/0:16/14617 está intentando adquirir bloqueo: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, en: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652 [...] pero la tarea ya mantiene el bloqueo: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, en: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572 La entrada del vecino pasó al estado NUD_FAILED, donde __neigh_event_send() desencadenó una Sondeo inmediato según el commit cd28ca0a3dd1 ("relincho: reducir la latencia de arp") a través de neigh_probe() dado que se mantuvo el bloqueo de la tabla. Una opción para solucionar esta situación es posponer neigh_probe() nuevamente a neigh_timer_handler() de manera similar a como se hacía antes de cd28ca0a3dd1. Para el caso de NTF_MANAGED, este aplazamiento es aceptable dado que esto solo ocurre en el estado de falla real y el estado normal/esperado es NUD_VALID con la entrada ya presente. La solución agrega un parámetro a __neigh_event_send() para comunicar si se permite o no la sonda inmediata. Los sitios de llamadas existentes de neigh_event_send() están predeterminados tal cual para la investigación inmediata. Sin embargo, neigh_managed_work() lo desactiva mediante el uso de neigh_event_send_probe(). [0] __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2956 [en línea] check_deadlock kernel/locking/lockdep.c :2999 [en línea] validar_chain kernel/locking/lockdep.c:3788 [en línea] __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5027 lock_acquire kernel/locking/lockdep.c:5639 [en línea] lock_acquire+0x1ab /0x510 kernel/locking/lockdep.c:5604 __raw_write_lock_bh include/linux/rwlock_api_smp.h:202 [en línea] _raw_write_lock_bh+0x2f/0x40 kernel/locking/spinlock.c:334 ___neigh_create+0x9e1/0x2990 net/core/neighbour.c :652 ip6_finish_output2+0x1070/0x14f0 net/ipv6/ip6_output.c:123 __ip6_finish_output net/ipv6/ip6_output.c:191 [en línea] __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170 poner+0x32/0x200 neto/ ipv6/ip6_output.c:201 NF_HOOK_COND include/linux/netfilter.h:296 [en línea] ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224 dst_output include/net/dst.h:451 [en línea] NF_HOOK include/ linux/netfilter.h:307 [en línea] ndisc_send_skb+0xa99/0x17f0 net/ipv6/ndisc.c:508 ndisc_send_ns+0x3a9/0x840 net/ipv6/ndisc.c:650 ndisc_solicit+0x2cd/0x4f0 net/ipv6/ndisc.c :742 neigh_probe+0xc2/0x110 net/core/neighbour.c:1040 __neigh_event_send+0x37d/0x1570 net/core/neighbour.c:1201 neigh_event_send include/net/neighbour.h:470 [en línea] neigh_managed_work+0x162/0x250 net/ core/neighbour.c:1574 Process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307 trabajador_thread+0x657/0x1110 kernel/workqueue.c:2454 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/ x86/entry/entry_64.S:295

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macsec: se corrigió el soporte de descarga para el evento NETDEV_UNREGISTER. El controlador de notificación netdev de macsec actual maneja el evento NETDEV_UNREGISTER liberando solo recursos SW relevantes, lo que provoca una pérdida de recursos en caso de descarga de HW de macsec, ya que No se notificó al controlador subyacente que limpiara sus recursos de descarga de macsec. Para solucionarlo, llame al controlador subyacente para limpiar sus recursos relevantes moviendo el manejo de descarga de macsec_dellink() a macsec_common_dellink() cuando se maneja el evento NETDEV_UNREGISTER.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: Reenviar activación a la cola de espera del socket smc después del respaldo Cuando reemplazamos TCP con SMC y se produce un respaldo, es posible que queden algunas entradas de la cola de espera del socket en el socket smc->wq. como eppoll_entries insertados por aplicaciones de espacio de usuario. Después del respaldo, los datos fluyen a través de TCP/IP y solo se activará clcsocket->wq. Las aplicaciones no pueden ser notificadas por las entradas que se insertaron en smc socket->wq antes del respaldo. Entonces necesitamos un mecanismo para activar smc socket->wq al mismo tiempo si quedan algunas entradas en él. La solución actual es transferir las entradas de smc socket->wq a clcsock->wq durante el respaldo. Pero esto puede causar un fallo como este: fallo de protección general, probablemente para la dirección no canónica 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 0 Comm: swapper/3 Kdump: cargado Contaminado: GE 5.16.0+ #107 RIP: 0010:__wake_up_common+0x65/0x170 Seguimiento de llamadas: __wake_up_common_lock+0x7a/0xc0 sock_def_readable+0x3c/0x70 tcp_data_queue+0x4a7/0xc40 tcp_rcv_establecido+0x32f/0x660 ? sk_filter_trim_cap+0xcb/0x2e0 tcp_v4_do_rcv+0x10b/0x260 tcp_v4_rcv+0xd2a/0xde0 ip_protocol_deliver_rcu+0x3b/0x1d0 ip_local_deliver_finish+0x54/0x60 0 ? tcp_v4_early_demux+0xa2/0x140? tcp_v4_early_demux+0x10d/0x140 ip_sublist_rcv_finish+0x49/0x60 ip_sublist_rcv+0x19d/0x230 ip_list_rcv+0x13e/0x170 __netif_receive_skb_list_core+0x1c2/0x240 netif_receive_skb_list_ interno+0x1e6/0x320 napi_complete_done+0x11d/0x190 mlx5e_napi_poll+0x163/0x6b0 [mlx5_core] __napi_poll+0x3c/0x1b0 net_rx_action+ 0x27c/0x300 __do_softirq+0x114/0x2d2 irq_exit_rcu+0xb4/0xe0 common_interrupt+0xba/0xe0 El bloqueo se debe a la transferencia privada de entradas de la cola de espera desde smc socket->wq a clcsock->wq. Los propietarios de estas entradas, como epoll, no tienen idea de que las entradas se han transferido a una cola de espera de socket diferente y aún usan el spinlock de cola de espera original (smc socket->wq.wait.lock) para que la operación de entradas sea exclusiva, pero no funciona. Las operaciones realizadas en las entradas, como la eliminación de la cola de espera (ahora es clcsock->wq después del respaldo), pueden causar un bloqueo cuando se está iterando sobre la cola de espera de clcsock en este momento. Este parche intenta solucionar este problema al no transferir las entradas de la cola de espera de forma privada, sino al introducir implementaciones propias de las funciones de devolución de llamada de clcsock en situaciones de reserva. Las funciones de devolución de llamada reenviarán la activación a smc socket->wq si clcsock->wq realmente se activa y smc socket->wq tiene entradas restantes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: ieee802154: ca8210: Detener la fuga de skb. En caso de error, no se llama al asistente ieee802154_xmit_complete(). Sólo se llama manualmente a ieee802154_wake_queue(). Luego filtramos la estructura skb. Libere la estructura skb en caso de error antes de regresar.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: uniphier: corrige la fuga del recuento de referencias en uniphier_spi_probe() El problema ocurre en varias rutas de error en uniphier_spi_probe(). Cuando dma_get_slave_caps() o devm_spi_register_master() devuelven un código de error, la función se olvida de disminuir el recuento de los objetos `dma_rx` y `dma_tx`, lo que puede provocar fugas de recuento. Corríjalo disminuyendo el recuento de referencias de objetos específicos en esas rutas de error.

Un usuario autenticado puede cargar archivos arbitrarios en la función de carga para imágenes de vista previa de la colección. Un atacante puede cargar un archivo HTML que incluya código JavaScript malicioso que se ejecutará si un usuario visita la URL directa de la imagen de vista previa de la colección (Stored Cross Site Scripting). También es posible cargar archivos SVG que incluyan entidades XML anidadas. Estos se analizan cuando un usuario visita la URL directa de la imagen de vista previa de la colección, que puede utilizarse para un ataque de denegación de servicio. Este problema afecta a edu-sharing: <8.0.8-RC2, <8.1.4-RC0, <9.0.0-RC19.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pciehp: soluciona el bucle infinito en el controlador IRQ ante un fallo de alimentación. El bit de fallo de alimentación detectado en el registro de estado de la ranura se diferencia de todos los demás eventos de conexión en caliente en que es fijo: solo puede borrarse después de apagar la alimentación de la ranura. Por PCIe r5.0, seg. 6.7.1.8: Si un controlador de energía detecta una falla de energía principal en la ranura de conexión en caliente, debe configurar automáticamente su pestillo interno de falla de energía principal [...]. El bloqueo de fallo de alimentación principal se borra cuando el software corta la alimentación a la ranura de conexión en caliente. La rigidez solía causar tormentas de interrupción y bucles infinitos que se solucionaron en 2009 mediante los commits 5651c48cfafe ("PCI pciehp: solucionar el problema de la tormenta de interrupción por falla de energía") y 99f0169c17f3 ("PCI: pciehp: habilitar la notificación de software en ranuras vacías"). Desafortunadamente, en 2020, el problema del bucle infinito se reintrodujo inadvertidamente mediante el commit 8edf5332c393 ("PCI: pciehp: arreglar carrera de interrupción MSI"): el controlador hardirq pciehp_isr() borra el bit PFD hasta que se establece el indicador power_fault_detected de pciehp. Eso sucede en el hilo IRQ pciehp_ist(), que nunca se entera del evento porque el controlador hardirq está atrapado en un bucle infinito. Para solucionarlo, configure el indicador power_fault_detected que ya está en el controlador hardirq.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9170/1: soluciona el pánico cuando kasan y kprobe están habilitados arm32 usa software para simular la instrucción reemplazada por kprobe. Algunas instrucciones pueden simularse mediante la construcción de funciones de ensamblaje. por lo tanto, antes de ejecutar la simulación de instrucciones, es necesario construir un entorno de ejecución de funciones de ensamblaje en lenguaje C mediante registros vinculantes. después de habilitar kasan, la relación de enlace de registros se destruirá, lo que provocará errores de simulación de instrucciones y provocará pánico en el kernel. La función de emulación de instrucciones de kprobe se distribuye en tres archivos: acciones-common.c acciones-arm.c acciones-thumb.c, por lo tanto, desactive KASAN al compilar estos archivos. por ejemplo, use kprobe insert en cap_capable+20 después de habilitar kasan, el código ensamblador de cap_capable es el siguiente: : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c agregue r0, r0, #108; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [ordenador personal, #144]; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108]; 0x6c e2859014 add r9, r5, #20 ...... El código ensamblador emulate_ldr después de habilitar kasan es el siguiente: c06f1384 : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c agregue r8, r2, #60; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load 4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f y sl, r5, #15 0a000001 beq c06f13bc e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, 4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 agregar r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 14 bne c06f1430 e1a06000 mov r6, r0 e2840040 agregar r0, r4, #64; 0x40 ...... cuando se ejecuta emulate_ldr para simular la instrucción ldr, se produce pánico y el registro es el siguiente: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, * pmd=00000000 Error interno: Ups: 206 [#1] La PC SMP ARM está en cap_capable+0x14/0xb0 LR está en emulate_ldr+0x50/0xc0 psr: 600d0293 sp: ecd63af8 ip: 00000004 fp: c0a7c30c r10: r9: c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Banderas: nZCv IRQ desactivadas FIQ activadas Modo SVC_3 2 Usuario de segmento ISA ARM Control: 32c5387d Tabla: 2d546400 DAC: 55555555 Proceso bash (pid: 1643, límite de pila = 0xecd60190) (cap_capable) de (kprobe_handler+0x218/0x340) (kprobe_handler) de (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) de (do_undefinstr+0x13c/0x364) (do_undefinstr) de (__ und_svc_finish+ 0x0/0x30) (__und_svc_finish) de (cap_capable+0x18/0xb0) (cap_capable) de (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) de (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) de (copy_process .constprop.5+0x16b4/ 0x25c8) (copy_process.constprop.5) de (_do_fork+0xe8/0x55c) (_do_fork) de (SyS_clone+0x1c/0x24) (SyS_clone) de (__sys_trace_return+0x0/0x10) Código: 0050a0e1 6c0080e2 0260a0e1 (f801f0e7)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Arreglar la reserva de colas para XDP Cuando se configuró XDP en un sistema con una gran cantidad de CPU y NIC X722, hubo un seguimiento de llamada con desreferencia de puntero NULL. i40e 0000:87:00.0: no se pudo obtener el seguimiento de 256 colas para VSI 0 err -12 i40e 0000:87:00.0: falló la configuración de VSI PRINCIPAL ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000000 RIP: 0010:i40e_xdp+0xea/ 0x1b0 [i40e] Seguimiento de llamadas:? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80? ata_qc_issue+0x107/0x1e0? lock_timer_base+0x61/0x80? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10? capacidad_seguridad+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copia_de_usuario+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 Esto fue causado por la fragmentación de la pila de cola PF debido al flujo La cola VSI del director se coloca justo después de la VSI principal. Debido a esto, la VSI principal no pudo cambiar el tamaño de su asignación de cola para XDP, lo que provocó que no se asignaran colas para la VSI principal cuando se activó XDP. Solucione este problema asignando siempre la última cola en la pila de colas PF para una VSI de director de flujo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: refactorización de verificación de datos publicitarios maliciosos. Se estaba realizando una verificación de lectura fuera de los límites al final del bucle while num_reports y llenaría el diario con falsos positivos. Se agregó una verificación al comienzo del procesamiento del bucle para que no se verifique después de que se haya avanzado ptr.