Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> xfrm: Corrección de fuga de rastreador de dispositivo<br /> <br /> En la etapa de las comprobaciones de dirección, el rastreador de referencias netdev ya está inicializado, pero liberado con una llamada *_put() incorrecta.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/srpt: Añadir una comprobación para un puntero &amp;#39;mad_agent&amp;#39; válido<br /> <br /> Al anular el registro del agente MAD, el módulo srpt tiene una comprobación de no nulidad para el puntero &amp;#39;mad_agent&amp;#39; antes de invocar ib_unregister_mad_agent().<br /> Esta comprobación puede pasar si la variable &amp;#39;mad_agent&amp;#39; contiene un valor de error.<br /> El &amp;#39;mad_agent&amp;#39; puede tener un valor de error durante una ventana corta cuando srpt_add_one() y srpt_remove_one() se ejecutan simultáneamente.<br /> <br /> En el módulo srpt, se añadió una comprobación de puntero válido para &amp;#39;sport-&amp;gt;mad_agent&amp;#39; antes de anular el registro del agente MAD.<br /> <br /> Este problema puede ocurrir cuando el controlador RoCE anula el registro de ib_device<br /> <br /> Traza de la pila:<br /> ------------<br /> BUG: desreferencia de puntero NULL del kernel, dirección: 000000000000004d<br /> PGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P<br /> Nombre del hardware: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020<br /> Cola de trabajo: bnxt_re bnxt_re_task [bnxt_re]<br /> RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40<br /> Traza de llamada:<br /> ib_unregister_mad_agent+0x46/0x2f0 [ib_core]<br /> IPv6: ADDRCONF(NETDEV_CHANGE): bond0: el enlace está listo<br /> ? __schedule+0x20b/0x560<br /> srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]<br /> srpt_remove_one+0x20/0x150 [ib_srpt]<br /> remove_client_context+0x88/0xd0 [ib_core]<br /> bond0: (esclavo p2p1): estado del enlace definitivamente activo, 100000 Mbps full duplex<br /> disable_device+0x8a/0x160 [ib_core]<br /> bond0: ¡interfaz activa levantada!<br /> ? kernfs_name_hash+0x12/0x80<br /> (dispositivo NULL *): Información de Bonding Recibida: rdev: 000000006c0b8247<br /> __ib_unregister_device+0x42/0xb0 [ib_core]<br /> (dispositivo NULL *): Maestro: modo: 4 num_slaves:2<br /> ib_unregister_device+0x22/0x30 [ib_core]<br /> (dispositivo NULL *): Esclavo: id: 105069936 nombre:p2p1 enlace:0 estado:0<br /> bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]<br /> bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath11k: Corrección de fuga de memoria en ath11k_peer_rx_frag_setup<br /> <br /> crypto_alloc_shash() asigna recursos, los cuales deben ser liberados por crypto_free_shash(). Cuando ath11k_peer_find() falla, ha habido una fuga de memoria. Añadir el crypto_free_shash() faltante para corregir esto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nfsd: mover la inicialización de los contadores percpu reply_cache_stats de vuelta a nfsd_init_net<br /> <br /> El commit f5f9d4a314da (&amp;#39;nfsd: mover la inicialización de la caché de respuestas al inicio de nfsd&amp;#39;) movió la inicialización de la caché de respuestas al inicio de nfsd, pero no tuvo en cuenta los contadores de estadísticas, los cuales pueden ser accedidos antes de que nfsd se inicie. El resultado puede ser una desreferencia de puntero NULL cuando alguien accede a /proc/fs/nfsd/reply_cache_stats mientras nfsd aún está apagado.<br /> <br /> Esto es una regresión y un oops activable por el usuario en la situación correcta:<br /> <br /> - arquitectura que no sea x86_64<br /> - /proc/fs/nfsd está montado en el espacio de nombres<br /> - nfsd no está iniciado en el espacio de nombres<br /> - usuario sin privilegios llama a &amp;#39;cat /proc/fs/nfsd/reply_cache_stats&amp;#39;<br /> <br /> Aunque esto es fácil de activar en algunas arquitecturas (como aarch64), en x86_64, llamar a this_cpu_ptr(NULL) evidentemente devuelve un puntero a los fixed_percpu_data. Esa estructura se parece lo suficiente a una variable percpu recién inicializada para permitir que nfsd_reply_cache_stats_show acceda a ella sin causar un Oops.<br /> <br /> Mover la inicialización de los contadores de caché de respuestas por-red+por-cpu de vuelta a nfsd_init_net, mientras se deja el resto de las asignaciones de la caché de respuestas para ser realizadas en el momento de inicio de nfsd.<br /> <br /> Felicitaciones a Eirik quien hizo la mayor parte del trabajo preliminar para rastrear esto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fbdev: udlfb: Corregir la verificación del punto final<br /> <br /> El fuzzer syzbot detectó un problema en el controlador udlfb, causado por un punto final que no tenía el tipo esperado:<br /> <br /> usb 1-1: Read EDID byte 0 failed: -71<br /> usb 1-1: Unable to get valid EDID from device/display<br /> ------------[ cut here ]------------<br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880<br /> drivers/usb/core/urb.c:504<br /> Modules linked in:<br /> CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted<br /> 6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google<br /> 04/28/2023<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> ...<br /> Call Trace:<br /> <br /> dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980<br /> dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315<br /> dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111<br /> dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743<br /> <br /> El enfoque actual para este problema no logró detectar el problema porque solo verifica la existencia de un punto final bulk-OUT; no verifica si este punto final es el que el controlador realmente utilizará.<br /> <br /> Podemos solucionar el problema al verificar en su lugar que el punto final utilizado por el controlador existe y es bulk-OUT.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> s390/vmem: dividir páginas cuando debug pagealloc está habilitado<br /> <br /> Desde el commit bb1520d581a3 (&amp;#39;s390/mm: iniciar kernel con DAT habilitado&amp;#39;), el kernel falla temprano durante el arranque cuando debug pagealloc está habilitado:<br /> <br /> inicialización automática de memoria: pila:desactivado, asignación de heap:desactivado, liberación de heap:desactivado<br /> excepción de direccionamiento: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOC<br /> Módulos enlazados:<br /> CPU: 0 PID: 0 Comm: swapper No contaminado 6.5.0-rc3-09759-gc5666c912155 #630<br /> [..]<br /> Código del kernel: 00000000001325f6: ec5600248064 cgrj %r5,%r6,8,000000000013263e<br /> 00000000001325fc: eb880002000c srlg %r8,%r8,2<br /> #0000000000132602: b2210051 ipte %r5,%r1,%r0,0<br /> &amp;gt;0000000000132606: b90400d1 lgr %r13,%r1<br /> 000000000013260a: 41605008 la %r6,8(%r5)<br /> 000000000013260e: a7db1000 aghi %r13,4096<br /> 0000000000132612: b221006d ipte %r6,%r13,%r0,0<br /> 0000000000132616: e3d0d0000171 lay %r13,4096(%r13)<br /> <br /> Traza de llamadas:<br /> __kernel_map_pages+0x14e/0x320<br /> __free_pages_ok+0x23a/0x5a8)<br /> free_low_memory_core_early+0x214/0x2c8<br /> memblock_free_all+0x28/0x58<br /> mem_init+0xb6/0x228<br /> mm_core_init+0xb6/0x3b0<br /> start_kernel+0x1d2/0x5a8<br /> startup_continue+0x36/0x40<br /> Pánico del kernel - no sincronizando: Excepción fatal: panic_on_oops<br /> <br /> Esto es causado por el uso de mapeos grandes en máquinas con EDAT1/EDAT2. Añadir el código para dividir los mapeos en páginas de 4k si debug pagealloc está habilitado por CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT o la opción de línea de comandos del kernel debug_pagealloc.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> MIPS: fw: Permitir que el firmware pase un &amp;#39;env&amp;#39; vacío<br /> <br /> fw_getenv utilizará la entrada &amp;#39;env&amp;#39; para determinar el estilo del &amp;#39;env&amp;#39;, sin embargo, es legal que el firmware simplemente pase una lista vacía.<br /> <br /> Comprobar si la primera entrada existe antes de ejecutar strchr para evitar la desreferencia de puntero nulo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cifs: corregir una posible condición de carrera al conectar el árbol ipc<br /> <br /> Proteger el acceso a TCP_Server_Info::hostname al construir el nombre del árbol ipc, ya que podría ser liberado en el hilo cifsd y así causar un error de uso después de liberación en __tree_connect_dfs_target(). Además, ya que estamos en ello, actualizar el estado de IPC tcon en caso de éxito y luego evitar cualquier conexión de árbol adicional.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/nouveau/kms/nv50-: inicializar hpd_irq_lock para PIOR DP<br /> <br /> Corrige OOPS en placas con codificadores DP ANX9805.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fs/sysv: Verificación de nulos para prevenir el error de desreferencia de puntero nulo<br /> <br /> sb_getblk(inode-&amp;gt;i_sb, parent) devuelve un puntero nulo y adquirir un bloqueo sobre eso conduce al error de desreferencia de puntero nulo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv6: Corrige un error de acceso a variable no inicializada en __ip6_make_skb()<br /> <br /> Syzbot informó un error como sigue:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]<br /> BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]<br /> BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]<br /> BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956<br /> arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]<br /> arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]<br /> atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]<br /> __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956<br /> ip6_finish_skb include/net/ipv6.h:1122 [inline]<br /> ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987<br /> rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579<br /> rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922<br /> inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530<br /> __sys_sendmsg net/socket.c:2559 [inline]<br /> __do_sys_sendmsg net/socket.c:2568 [inline]<br /> __se_sys_sendmsg net/socket.c:2566 [inline]<br /> __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> La no inicialización fue creada en:<br /> slab_post_alloc_hook mm/slab.h:766 [inline]<br /> slab_alloc_node mm/slub.c:3452 [inline]<br /> __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491<br /> __do_kmalloc_node mm/slab_common.c:967 [inline]<br /> __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988<br /> kmalloc_reserve net/core/skbuff.c:492 [inline]<br /> __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565<br /> alloc_skb include/linux/skbuff.h:1270 [inline]<br /> __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684<br /> ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854<br /> rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915<br /> inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530<br /> __sys_sendmsg net/socket.c:2559 [inline]<br /> __do_sys_sendmsg net/socket.c:2568 [inline]<br /> __se_sys_sendmsg net/socket.c:2566 [inline]<br /> __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Esto se debe a que icmp6hdr no está en la región lineal de skb bajo el escenario del socket SOCK_RAW. Acceder a icmp6_hdr(skb)-&amp;gt;icmp6_type directamente activará el error de acceso a variable no inicializada.<br /> <br /> Usa una variable local icmp6_type para llevar el valor correcto en diferentes escenarios.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: dvb-usb: m920x: Corrige una posible fuga de memoria en m920x_i2c_xfer()<br /> <br /> &amp;#39;read&amp;#39; se libera cuando se sabe que es NULL, pero no cuando ocurre un error de lectura.<br /> <br /> Revierte la lógica para evitar una pequeña fuga, en caso de que una llamada a m920x_read() falle.