Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: cmd-db: Asignar memoria compartida como WC, no como WB Linux no escribe en la región cmd-db. Esta región de memoria está protegida contra escritura por XPU. En ocasiones, XPU puede detectar erróneamente la expulsión de caché limpia como "escritura" en la región protegida contra escritura, lo que genera una interrupción segura que provoca un bucle sin fin en algún lugar de la Zona de confianza. La única razón por la que funciona en este momento es porque Qualcomm Hypervisor asigna la misma región que la memoria no almacenable en caché en las tablas de traducción de la Etapa 2. El problema se manifiesta si queremos usar otro hipervisor (como Xen o KVM), que no sabe nada sobre esas asignaciones específicas. Cambiar la asignación de memoria cmd-db de MEMREMAP_WB a MEMREMAP_WT/WC elimina la dependencia de las asignaciones correctas en las tablas de la Etapa 2. Este parche corrige el problema actualizando la asignación a MEMREMAP_WC. Probé esto en SA8155P con Xen.

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: nfsd: evitar pánico para archivos cerrados nfsv4.0 en nfs4_show_open Antes del commit 3f29cc82a84c ("nfsd: separar sc_status de sc_type") states_show() dependía de que el campo sc_type fuera de un tipo válido antes de llamar a una subfunción para mostrar el contenido de un stateid en particular. A partir de esa confirmación, dividimos la validez del stateid en sc_status y ya no cambiamos sc_type a 0 mientras deshacemos el hash del stateid. Esto resultó en un error del kernel para las aperturas nfsv4.0 que permanecen y en nfs4_show_open() se desreferenciaba sc_file que era NULL. En cambio, para los stateids abiertos y cerrados, renunciamos a mostrar información que depende de tener un sc_file válido. Para reproducir: monte el servidor con 4.0, lea y cierre un archivo y luego en el servidor cat /proc/fs/nfsd/clients/2/states [ 513.590804] Rastreo de llamadas: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0 [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896] seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [513.592241] ksys_read+0xcc/0x178

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: 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: 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: 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).

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: drm/xe: evitar UAF alrededor de la cerca de preempción El bloqueo de la cerca es parte de la cola, por lo tanto, en el diseño actual, cualquier cosa que bloquee la cerca también debe contener una referencia a la cola para evitar que la cola se libere. Sin embargo, actualmente parece que le enviamos una señal a la cerca y luego descartamos la referencia de la cola, pero si algo está esperando en la cerca, el que espera es expulsado para que se despierte en algún momento posterior, donde al despertarse primero toma el bloqueo antes de verificar el estado de la cerca. Pero si ya descartamos la referencia de la cola, entonces el bloqueo ya podría estar liberado como parte de la cola, lo que lleva a uaf. Para evitar esto, mueva el bloqueo de la cerca a la cerca misma para que no nos encontremos con problemas de duración de vida. La alternativa podría ser tener un bloqueo a nivel de dispositivo, o solo liberar la cola en la devolución de llamada de liberación de la cerca, sin embargo, eso podría requerir enviar a otro trabajador para evitar problemas de bloqueo. Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454 Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342 Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020 (seleccionada del commit 7116c35aacedc38be6d15bd21b2fc936eed0008b)