Vulnerabilidades

Las unidades de estado sólido Micron Crucial serie MX500 M3CR046 son vulnerables a desbordamiento de búfer, que puede ser activado al enviar paquetes ATA especialmente diseñados desde el host al controlador de la unidad. NOTA: El proveedor afirma que esta vulnerabilidad fue completamente subsanada en diciembre de 2024 y que el firmware actualizado está disponible a través de la página de soporte oficial de Crucial.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evitar UAF en ip6_send_skb() syzbot informó de un UAF en ip6_send_skb() [1] Después de que ip6_local_out() haya regresado, ya no podemos desreferenciar rt de forma segura, a menos que mantengamos rcu_read_lock(). Se ha solucionado un problema similar en el commit a688caa34beb ("ipv6: tomar bloqueo rcu en rawv6_send_hdrinc()") Otro problema potencial en ip6_finish_output2() se maneja en un parche independiente. [1] ERROR: KASAN: slab-use-after-free en ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 Lectura de tamaño 8 en la dirección ffff88806dde4858 por la tarea syz.1.380/6530 CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 No contaminado 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 descripción_dirección_impresión mm/kasan/report.c:377 [en línea] informe_impresión+0x169/0x550 mm/kasan/report.c:488 informe_kasan+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 tramas_pendientes_de_envío_sin_formato_v6+0x75c/0x9e0 net/ipv6/raw.c:588 envío_sin_formato_v6+0x19c7/0x23c0 net/ipv6/raw.c:926 envío_sin_formato_v6_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f DESCANSE EN PÉRDIDA: 0033:0x7f936bf79e79 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 00000000000000014 RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79 RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000000246 R12: 00000000000000000 R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 Asignado por la tarea 6530: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [en línea] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [en línea] slab_post_alloc_hook mm/slub.c:3988 [en línea] slab_alloc_node mm/slub.c:4037 [en línea] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [en línea] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [en línea] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Liberado por la tarea 45: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [en línea] slab_free_hook mm/slub.c:2252 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, slub: no llamar a do_slab_free para el objeto kfence En 782f8906f805, la liberación de objetos kfence se trasladó desde lo profundo de do_slab_free a las funciones envolventes externas. Este es un cambio agradable, pero desafortunadamente omitió un punto en __kmem_cache_free_bulk. Esto da como resultado un fallo como este: ERROR skbuff_head_cache (Tainted: GSBE ): Relleno sobrescrito. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840 error_losa (mm/slub.c:1129) lista_libre_a_parcial (mm/slub.c:? mm/slub.c:4036) comprobación_almohadilla_losa (mm/slub.c:864 mm/slub.c:1290) comprobación_losa (mm/slub.c:?) lista_libre_a_parcial (mm/slub.c:3171 mm/slub.c:4036) kmem_cache_alloc_bulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635) napi_build_skb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549) Todos los demás llamadores de do_slab_free parecen estar bien. Agregue una comprobación de kfence_free en __kmem_cache_free_bulk para evitar el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no borrar la página sucia dentro de extended_write_locked_range() [ERROR] Para el caso de subpágina + zonificación, la siguiente carga de trabajo puede provocar una fuga de datos de rsv en el momento del desmontaje: # mkfs.btrfs -f -s 4k $dev # mount $dev $mnt # fsstress -w -n 8 -d $mnt -s 1709539240 0/0: fiemap - sin nombre de archivo 0/1: copyrange read - sin nombre de archivo 0/2: write - sin nombre de archivo 0/3: rename - sin nombre de archivo de origen 0/4: creat f0 x:0 0 0 0/4: creat add id=0,parent=-1 0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0 0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1 0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat() 0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0 # umount $mnt El dmesg incluye la siguiente advertencia de detección de fugas de rsv (se omite todo el seguimiento de llamadas): ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 4528 en fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs] ---[ fin del seguimiento 000000000000000 ]--- ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 4528 en fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs] ---[ fin del seguimiento 000000000000000 ]--- ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 4528 en fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs] ---[ fin del seguimiento 000000000000000 ]--- Información de BTRFS (dispositivo sda): último desmontaje del sistema de archivos 1b4abba9-de34-4f07-9e7f-157cf12a18d6 ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 3 PID: 4528 en fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs] ---[ fin del seguimiento 000000000000000 ]--- Información de BTRFS (dispositivo sda): space_info DATA tiene 268218368 libres, no está lleno Información de BTRFS (dispositivo sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0 BTRFS información (dispositivo sda): global_block_rsv: tamaño 0 reservado 0 información BTRFS (dispositivo sda): trans_block_rsv: tamaño 0 reservado 0 información BTRFS (dispositivo sda): chunk_block_rsv: tamaño 0 reservado 0 información BTRFS (dispositivo sda): delayed_block_rsv: tamaño 0 reservado 0 información BTRFS (dispositivo sda): delayed_refs_rsv: tamaño 0 reservado 0 ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 3 PID: 4528 en fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs] ---[ fin de seguimiento 000000000000000 ]--- información BTRFS (dispositivo sda): space_info METADATA tiene 267796480 libres, es Información BTRFS no completa (dispositivo sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760 Información BTRFS (dispositivo sda): global_block_rsv: tamaño 0 reservado 0 Información BTRFS (dispositivo sda): trans_block_rsv: tamaño 0 reservado 0 Información BTRFS (dispositivo sda): chunk_block_rsv: tamaño 0 reservado 0 Información BTRFS (dispositivo sda): delayed_block_rsv: tamaño 0 reservado 0 Información BTRFS (dispositivo sda): delayed_refs_rsv: tamaño 0 reservado 0 Arriba $dev es un HDD zonificado emulado tcmu-runner, que tiene un tamaño máximo de anexión de zona de 64K, y el sistema tiene un tamaño de página de 64K. [CAUSA] He añadido varios trace_printk() para mostrar los eventos (encabezado omitido): > btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688 > btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288 > btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536 > btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864 Las líneas anteriores muestran que nuestra escritura en búfer ha ensuciado 3 páginas de inodo 259 de la raíz 5: 704K 768K 832K 896K --- truncado ----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binfmt_flat: Se corrige la corrupción cuando no se compensa el inicio de los datos. El commit 04d82a6d0881 ("binfmt_flat: permitir no compensar el inicio de los datos") introdujo una variante específica de RISC-V del formato FLAT que no asigna ningún espacio para la matriz (obsoleta) de punteros de librería compartida. Sin embargo, no deshabilitó el código que inicializa la matriz, lo que resultó en la corrupción de sizeof(long) bytes antes del segmento DATA, generalmente el final del segmento TEXT. Introduzca MAX_SHARED_LIBS_UPDATE que depende del estado de CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET para proteger la inicialización de la región del puntero de la librería compartida de modo que solo se inicialice si se reserva espacio para ella.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mgag200: vincular la vida útil de I2C al dispositivo DRM La limpieza administrada con devm_add_action_or_reset() liberará el adaptador I2C cuando el dispositivo Linux subyacente desaparezca. Pero el conector aún hace referencia a él, por lo que esta limpieza deja un puntero obsoleto en struct drm_connector.ddc. Vincule la vida útil del adaptador I2C a la vida útil del conector mediante la liberación administrada de DRM. Cuando el dispositivo DRM desaparezca (después del dispositivo Linux), DRM primero limpiará el conector y luego limpiará el adaptador I2C.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tick/broadcast: mover el acceso al puntero por CPU a la sección atómica La solución reciente para hacer que la toma de control del temporizador de difusión sea más fiable recupera un puntero por CPU en un contexto preemptible. Esto pasó desapercibido ya que los compiladores elevan el acceso a la región no preemptible donde realmente se usa el puntero. Pero, por supuesto, es válido que el compilador lo mantenga en el lugar donde lo pone el código, lo que activa correctamente: ERROR: usar smp_processor_id() en código preemptible [00000000]: el llamador es hotplug_cpu__broadcast_tick_pull+0x1c/0xc0 Muévalo al sitio de uso real que está en una región no preemptible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/sclp: Impedir la liberación de búfer en E/S Cuando se interrumpe una tarea que espera la finalización de una operación de almacenamiento de datos, se intenta detener esta operación. Si este intento falla debido a un problema de hardware o firmware, existe la posibilidad de que la función SCLP almacene datos en búferes a los que hace referencia la operación original en un momento posterior. Maneje esta situación al no liberar los búferes de datos a los que hace referencia si el intento de detención falla. Para los casos de uso actuales, esto podría resultar en una pérdida de algunas páginas de memoria en caso de un mal funcionamiento poco común del hardware o firmware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: SHAMPO, soluciona la desvinculación de la lista enlazada de WQ no válida Cuando se han consumido todos los pasos en un WQE, el WQE se desvincula de la lista enlazada de WQ (mlx5_wq_ll_pop()). Para SHAMPO, es posible recibir CQE con 0 pasos consumidos para el mismo WQE incluso después de que el WQE se haya consumido por completo y se haya desvinculado. Esto desencadena una desvinculación adicional para el mismo wqe que corrompe la lista enlazada. Solucione este escenario aceptando pasos consumidos de tamaño 0 sin desvincular el WQE nuevamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: bcm_sf2: Se corrige una posible pérdida de memoria en bcm_sf2_mdio_register() bcm_sf2_mdio_register() llama a of_phy_find_device() y luego a phy_device_remove() en un bucle para eliminar los dispositivos PHY existentes. of_phy_find_device() finalmente llama a bus_find_device(), que llama a get_device() en el struct device * devuelto para incrementar el refcount. La implementación actual no disminuye el refcount, lo que causa una pérdida de memoria. Esta confirmación agrega la llamada phy_device_free() faltante para disminuir el refcount a través de put_device() para equilibrar el refcount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: sc16is7xx: fix TX fifo democracy A veces, cuando se recibe un paquete en el canal A casi al mismo tiempo que se va a transmitir un paquete en el canal B, observamos con un analizador lógico que el paquete recibido en el canal A se transmite en el canal B. En otras palabras, los datos del búfer de Tx en el canal B están dañados con datos del canal A. El problema apareció desde el commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock to operate on each channels"), que cambió el bloqueo de EFR para que funcione en cada canal en lugar de en todo el chip. Este commit ha introducido una regresión, porque el bloqueo de EFR se utiliza no solo para proteger el acceso a los registros de EFR, sino también, de una forma muy oscura y no documentada, para proteger el acceso al búfer de datos, que es compartido por los manejadores de Tx y Rx, pero también por cada canal del IC. Primero, solucione esta regresión cambiando a kfifo_out_linear_ptr() en sc16is7xx_handle_tx() para eliminar la necesidad de un búfer Rx/Tx compartido. En segundo lugar, reemplace el búfer Rx por chip con un búfer Rx separado para cada canal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: se corrige uevent_show() frente a la ejecución de desconexión del controlador uevent_show() quiere desreferenciar dev->driver->name. No hay una forma clara de que un atributo de dispositivo desreferenciar dev->driver a menos que ese atributo se defina mediante (struct device_driver).dev_groups. En cambio, el antipatrón de tomar device_lock() en el controlador de atributos corre el riesgo de bloqueos con rutas de código que eliminan los atributos del dispositivo mientras mantienen el bloqueo. Este interbloqueo es típicamente invisible para lockdep dado que device_lock() está marcado como lockdep_set_novalidate_class(), pero algunos subsistemas asignan una clave lockdep local para que @dev->mutex revele informes del formato: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 está intentando adquirir el bloqueo: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, en: __kernfs_remove+0xde/0x220 pero la tarea ya tiene el bloqueo: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, en: device_release_driver_internal+0x39/0x210 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Sin embargo, la observación es que los objetos de controlador suelen tener una vida útil mucho más larga que los objetos de dispositivo. Es razonable realizar una desreferencia sin bloqueo de un puntero @driver incluso si está compitiendo por desconectarse de un dispositivo. Dada la poca frecuencia de anulación del registro de un controlador, usesynchronous_rcu() en module_remove_driver() para cerrar cualquier ejecución potencial. Es potencialmente excesivo sufrirsynchronous_rcu() solo para manejar el raro evento uevent_show() de ejecución de eliminación de módulo. Gracias a Tetsuo Handa por el análisis de depuración del informe de syzbot [1].