Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: ucsi: Move unregister out of atomic section El Commit '9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")' movió la lista de clientes pmic_glink bajo un spinlock, ya que es accedida por la devolución de llamada rpmsg/glink, que a su vez se invoca desde el contexto IRQ. Esto significa que ucsi_unregister() ahora se llama desde el contexto atómico, lo que no es factible ya que espera un contexto durmiente. Se está realizando un esfuerzo para lograr que GLINK invoque sus devoluciones de llamada en un contexto durmiente, pero hasta entonces, programemos la anulación del registro. Un efecto secundario de esto es que ucsi_unregister() ahora puede suceder después de que el procesador remoto, y por lo tanto el enlace de comunicación con él, se haya ido. pmic_glink_send() se modifica con una verificación para evitar la desreferencia de puntero NULL resultante. Sin embargo, esto hace que el usuario sea informado sobre este error mediante la siguiente entrada en el registro del núcleo: ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: no se pudo enviar la solicitud de escritura UCSI: -5

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: single: se corrige una posible desreferenciación de NULL en pcs_get_function(). pinmux_generic_get_function() puede devolver NULL y el puntero 'función' se desreferenciaba sin comprobar si era NULL. Se ha añadido la comprobación del puntero 'función' en pcs_get_function(). Se ha encontrado mediante una revisión de código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb/client: evitar desreferenciar rdata=NULL en smb2_new_read_req() Esto sucede cuando se llama desde SMB2_read() mientras se usa rdma y se alcanza rdma_readwrite_threshold.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige un Use After Free al encontrar errores dentro de btrfs_submit_chunk() [BUG] Hay un informe interno de que KASAN informa un Use After Free, con el siguiente backtrace: BUG: KASAN: slab-use-after-free en btrfs_check_read_bio+0xa68/0xb70 [btrfs] Lectura de tamaño 4 en la dirección ffff8881117cec28 por la tarea kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 No contaminado 6.11.0-rc2-next-20240805-default+ #76 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 01/04/2014 Cola de trabajo: btrfs-endio btrfs_end_bio_work [btrfs] Seguimiento de llamadas: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x5e/0x2f0 print_report+0x118/0x216 kasan_report+0x11d/0x1f0 btrfs_check_read_bio+0xa68/0xb70 [btrfs] process_one_work+0xce0/0x12a0 worker_thread+0x717/0x1250 kthread+0x2e3/0x3c0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Asignado por la tarea 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x7d/0x80 kmem_cache_alloc_noprof+0x16e/0x3e0 mempool_alloc_noprof+0x12e/0x310 bio_alloc_bioset+0x3f0/0x7a0 btrfs_bio_alloc+0x2e/0x50 [btrfs] enviar_extensión_página+0x4d1/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] lectura_páginas+0x1a7/0xc60 caché_página_sin_límites+0x2ad/0x560 mapa_archivo_obtener_páginas+0x629/0xa20 mapa_archivo_leer+0x335/0xbf0 lectura_vfs+0x790/0xcb0 lectura_ksys+0xfd/0x1d0 llamada_al_sistema_64+0x6d/0x140 entrada_SYSCALL_64_después_hwframe+0x4b/0x53 Liberado por la tarea 20917: pila_guardado_kasan+0x37/0x60 pista_guardado_kasan+0x10/0x30 información_libre_guardado_kasan+0x37/0x50 __kasan_slab_free+0x4b/0x60 kmem_cache_free+0x214/0x5d0 bio_free+0xed/0x180 end_bbio_data_read+0x1cc/0x580 [btrfs] btrfs_submit_chunk+0x98d/0x1880 [btrfs_submit_bio+0x33/0x7 0 [btrfs] submit_one_bio+0xd4/0x130 [btrfs] submit_extent_page+0x3ea/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSA] Aunque no puedo reproducir el error, el informe en sí es lo suficientemente bueno como para determinar la causa. El seguimiento de llamadas es el contexto de la cola de trabajo de endio normal, pero el seguimiento de liberación por tarea muestra que durante btrfs_submit_chunk() ya encontramos un error crítico y está llamando a btrfs_bio_end_io() para que se solucione el error. Y la función endio original llamó a bio_put() para liberar todo el bio. Esto significa una doble liberación, lo que provoca un Use After Free, por ejemplo: 1. Ingrese a btrfs_submit_bio() con una biografía leída La longitud de la biografía leída es de 128K, cruzando dos franjas de 64K. 2. La primera ejecución de btrfs_submit_chunk() 2.1 Llame a btrfs_map_block(), que devuelve 64K 2.2 Llame a btrfs_split_bio() Ahora hay dos biografías, una que hace referencia a los primeros 64K, la otra que hace referencia a los segundos 64K. 2.3 Se envía la primera mitad. 3. La segunda ejecución de btrfs_submit_chunk() 3.1 Llamar a btrfs_map_block(), que de alguna manera falló Ahora llamamos a btrfs_bio_end_io() para manejar el error 3.2 btrfs_bio_end_io() llama a la función endio original que es end_bbio_data_read(), y llama a bio_put() para el bio original. Ahora el bio original está liberado. 4. El primer bio de 64K enviado terminó Ahora llamamos a btrfs_check_read_bio() e intentamos avanzar el iter del bio. Pero como el bio original (y por lo tanto su iter) ya está liberado, activamos el use-after free anterior. E incluso si la memoria no está envenenada/corrompida, luego llamaremos a la función endio original, causando una doble liberación. [SOLUCIÓN] En lugar de llamar a btrfs_bio_end_io(), --truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: core: Impedir el acceso a una dirección de búfer de eventos no válida del núcleo USB Esta confirmación soluciona un problema en el que el núcleo USB podría acceder a una dirección de búfer de eventos no válida durante la suspensión en tiempo de ejecución, lo que podría provocar fallos de SMMU y otros problemas de memoria en las plataformas Exynos. El problema surge de la siguiente secuencia. 1. En dwc3_gadget_suspend, existe la posibilidad de que se agote el tiempo de espera al mover el núcleo USB al estado de detención después de borrar el bit de ejecución/detención por software. 2. En dwc3_core_exit, el búfer de eventos se borra independientemente del estado del núcleo USB, lo que puede provocar fallos de SMMU y otros problemas de memoria si el núcleo USB intenta acceder a la dirección del búfer de eventos. Para evitar esta peculiaridad del hardware en las plataformas Exynos, esta confirmación garantiza que el software no borre la dirección del búfer de eventos cuando el núcleo USB esté activo durante la suspensión en tiempo de ejecución comprobando su estado antes de borrar la dirección del búfer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: pn533: Añadir comprobación de llenado de lista de mod de sondeo En caso de que el valor de im_protocols sea 1 y el valor de tm_protocols sea 0, esta combinación pasa con éxito la comprobación 'if (!im_protocols && !tm_protocols)' en nfc_start_poll(). Pero luego, después de la llamada a pn533_poll_create_mod_list() en pn533_start_poll(), la lista de mod de sondeo permanecerá vacía y dev->poll_mod_count permanecerá en 0, lo que conduce a la división por cero. Normalmente, ningún protocolo im tiene el valor 1 en la máscara, por lo que el controlador no espera esta combinación. Pero estos valores de protocolo en realidad provienen del espacio de usuario a través de la interfaz Netlink (operación NFC_CMD_START_POLL). Por lo tanto, un programa dañado o malicioso puede enviar un mensaje que contenga una combinación "mala" de valores de parámetros de protocolo, de modo que dev->poll_mod_count no se incremente dentro de pn533_poll_create_mod_list(), lo que lleva a una división por cero. El seguimiento de la llamada se ve así: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Agregar comprobación de llenado de la lista de mods de sondeo. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: cambiar ipsec_lock de spin lock a mutex en el commit citado, se agrega bond->ipsec_lock para proteger ipsec_list, por lo tanto, se llaman xdo_dev_state_add y xdo_dev_state_delete dentro de este bloqueo. Como ipsec_lock es un spin lock y tales operaciones xfrmdev pueden dormir, se activará "programación mientras es atómica" al cambiar el esclavo activo de bond. [ 101.055189] ERROR: programación mientras es atómica: bash/902/0x00000200 [ 101.055726] Módulos vinculados en: [ 101.058211] CPU: 3 PID: 902 Comm: bash No contaminado 6.9.0-rc4+ #1 [ 101.058760] Nombre del hardware: [ 101.059434] Seguimiento de llamadas: [ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? opción_almacenamiento_sysfs_bonding+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] cambio_enlace_esclavo_activo+0x392/0x900 [enlace] [ 101.069868] opción_enlace_esclavo_activo_conjunto+0x1c2/0x240 [enlace] [ 101.070454] __opción_enlace_conjunto+0xa6/0x430 [enlace] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [vinculación] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [vinculación] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [vinculación] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53 Como bond_ipsec_add_sa_all y bond_ipsec_del_sa_all solo se llaman desde bond_change_active_slave, que requiere mantener el bloqueo RTNL. Y bond_ipsec_add_sa y bond_ipsec_del_sa son API xdo_dev_state_add y xdo_dev_state_delete de estado xfrm, que están en el contexto del usuario. Por lo tanto, ipsec_lock no tiene que ser un bloqueo de giro; cámbielo a mutex y, por lo tanto, se puede resolver el problema anterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethtool: comprobar la presencia del dispositivo al obtener la configuración del enlace Un lector sysfs puede competir con un reinicio o eliminación del dispositivo, intentando leer el estado del dispositivo cuando este no está realmente presente. p. ej.: [excepción RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings en ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings en ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings en ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show en ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show en ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show en ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read en ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read en ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read en ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 en ffffffff98a052fb bloqueo> estructura net_device.state ffff9a9d21336000 estado = 5, el estado 5 es __LINK_STATE_START (0b1) y __LINK_STATE_NOCARRIER (0b100). El dispositivo no está presente, note la falta de __LINK_STATE_PRESENT (0b10). Este es el mismo tipo de pánico que se observa en el commit 4224cfd7fb65 ("net-sysfs: agregar verificación de presencia de netdevice a speed_show"). Hay muchos otros invocadores de __ethtool_get_link_ksettings() que no tienen una verificación de presencia de dispositivo. Mueva esta verificación a ethtool para proteger a todos los invocadores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btnxpuart: corrige un bloqueo aleatorio observado al eliminar el controlador Esto corrige el bloqueo aleatorio del kernel observado al eliminar el controlador, al ejecutar la prueba de carga/descarga en múltiples iteraciones. 1) modprobe btnxpuart 2) hciconfig hci0 reset 3) hciconfig (verifique que la interfaz hci0 esté activa con una dirección BD válida) 4) modprobe -r btnxpuart Repita los pasos 1 a 4 La llamada ps_wakeup() en btnxpuart_close() programa psdata->work(), que se programa después de que se elimina el módulo, lo que provoca un bloqueo del kernel. Este problema oculto se destacó después de habilitar el Ahorro de energía de forma predeterminada en 4183a7be7700 (Bluetooth: btnxpuart: Habilitar la función Ahorro de energía al inicio). El nuevo ps_cleanup() anula la interrupción de UART inmediatamente al cerrar el dispositivo serdev, cancela cualquier ps_work programado y destruye el mutex ps_lock. [ 85.884604] No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffffd4a61638f258 [ 85.884624] Información de aborto de memoria: [ 85.884625] ESR = 0x0000000086000007 [ 85.884628] EC = 0x21: IABT (EL actual), IL = 32 bits [ 85.884633] SET = 0, FnV = 0 [ 85.884636] EA = 0, S1PTW = 0 [ 85.884638] FSC = 0x07: error de traducción de nivel 3 [ 85.884642] tabla de páginas del intercambiador: 4k páginas, VA de 48 bits, pgdp=0000000041dd0000 [ 85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000 [ 85.884662] Error interno: Oops: 0000000086000007 [#1] PREEMPT SMP [ 85.890932] Módulos vinculados en: algif_hash algif_skcipher af_alg superposición fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 error de seguridad de caam snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv fusible rc_core [última descarga: btnxpuart(O)] [ 85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Contaminado: GO 6.1.36+g937b1be4345a #1 [ 85.936176] Nombre del hardware: Placa EVK FSL i.MX8MM (DT) [ 85.936182] Cola de trabajo: eventos 0xffffd4a61638f380 [ 85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 85.952817] pc : 0xffffd4a61638f258 [ 85.952823] lr : 0xffffd4a61638f258 [ 85.952827] sp : ffff8000084fbd70 [ 85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000 [ 85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305 [ 85.963119] ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970 [ 85.977382] x20: 00000000000000000 x19: ffff4bf1c8540880 x18: 00000000000000 00 [ 85.977391] x17: 0000000000000000 x16: 00000000000000133 x15: 0000ffffe2217090 [ 85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139 [ 85.977407] x11: 000000000000001 x10: 0000000000000a60 x9: ffff8000084fbc50 [ 85.977417] x8: ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8 [ 85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000 [ 85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000 [ 85.977443] Rastreo de llamadas: [ 85.977446] 0xffffd4a61638f258 [ 85.977451] 0xffffd4a61638f3e8 [ 85.977455] process_one_work+0x1d4/0x330 [ 85.977464] worker_thread+0x6c/0x430 [ 85.977471] kthread+0x108/0x10c [ 85.977476] ret_from_fork+0x10/0x20 [ 85.977488] Código: valor de PC incorrecto [ 85.977491] ---[ fin de seguimiento 0000000000000000 ]--- Preestablecido desde v6.9.11

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pktgen: uso de cpus_read_lock() en pg_net_init() He visto que WARN_ON(smp_processor_id() != cpu) se activa en pktgen_thread_worker() durante las pruebas. Debemos usar cpus_read_lock()/cpus_read_unlock() alrededor del bucle for_each_online_cpu(cpu). Mientras estamos en ello, use WARN_ON_ONCE() para evitar una posible inundación de syslog.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: st: fix probed platform device ref count on probe error path La función de sonda nunca realiza ninguna asignación de dispositivo de plataforma, por lo que la ruta de error "undo_platform_dev_alloc" es completamente falsa. Elimina el recuento de referencia del dispositivo de plataforma que se está sondeando. Si se activa la ruta de error, esto provocará recuentos de referencia de dispositivo desequilibrados y una liberación prematura de los recursos del dispositivo, por lo que es posible que se produzca un use-after-free al liberar los recursos restantes administrados por devm.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gtp: se corrige una posible desreferencia de puntero NULL Cuando sockfd_lookup() falla, gtp_encap_enable_socket() devuelve un puntero NULL, pero sus invocadores solo comprueban los punteros de error, por lo que pasan por alto el caso del puntero NULL. Arréglelo devolviendo un puntero de error con el código de error que lleva sockfd_lookup(). (Encontré este error durante la inspección del código).