Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mlxsw: spectrum_router: Corrección de uso después de liberación de vecino<br /> <br /> A veces observamos uso después de liberación al desreferenciar un vecino [1].<br /> El problema parece ser que el controlador almacena un puntero al vecino, pero sin mantener una referencia sobre él. Solo se toma una referencia cuando el vecino es utilizado por un nexthop.<br /> <br /> Corrección simplificando el esquema de conteo de referencias. Siempre se toma una referencia al almacenar un puntero de vecino en una entrada de vecino. Evitar tomar una referencia cuando el vecino es utilizado por un nexthop ya que la entrada de vecino asociada con el nexthop ya mantiene una referencia.<br /> <br /> Probado ejecutando la prueba que descubrió el problema más de 300 veces. Sin este parche el problema se reprodujo después de un puñado de iteraciones.<br /> <br /> [1]<br /> BUG: KASAN: uso después de liberación de slab en mlxsw_sp_neigh_entry_update+0x2d4/0x310<br /> Lectura de tamaño 8 en la dirección ffff88817f8e3420 por la tarea ip/3929<br /> <br /> CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)<br /> Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023<br /> Rastro de Llamada:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_address_description.constprop.0+0x6e/0x300<br /> print_report+0xfc/0x1fb<br /> kasan_report+0xe4/0x110<br /> mlxsw_sp_neigh_entry_update+0x2d4/0x310<br /> mlxsw_sp_router_rif_gone_sync+0x35f/0x510<br /> mlxsw_sp_rif_destroy+0x1ea/0x730<br /> mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0<br /> __mlxsw_sp_inetaddr_lag_event+0xcc/0x130<br /> __mlxsw_sp_inetaddr_event+0xf5/0x3c0<br /> mlxsw_sp_router_netdevice_event+0x1015/0x1580<br /> notifier_call_chain+0xcc/0x150<br /> call_netdevice_notifiers_info+0x7e/0x100<br /> __netdev_upper_dev_unlink+0x10b/0x210<br /> netdev_upper_dev_unlink+0x79/0xa0<br /> vrf_del_slave+0x18/0x50<br /> do_set_master+0x146/0x7d0<br /> do_setlink.isra.0+0x9a0/0x2880<br /> rtnl_newlink+0x637/0xb20<br /> rtnetlink_rcv_msg+0x6fe/0xb90<br /> netlink_rcv_skb+0x123/0x380<br /> netlink_unicast+0x4a3/0x770<br /> netlink_sendmsg+0x75b/0xc90<br /> __sock_sendmsg+0xbe/0x160<br /> ____sys_sendmsg+0x5b2/0x7d0<br /> ___sys_sendmsg+0xfd/0x180<br /> __sys_sendmsg+0x124/0x1c0<br /> do_syscall_64+0xbb/0xfd0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [...]<br /> <br /> Asignado por la tarea 109:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7b/0x90<br /> __kmalloc_noprof+0x2c1/0x790<br /> neigh_alloc+0x6af/0x8f0<br /> ___neigh_create+0x63/0xe90<br /> mlxsw_sp_nexthop_neigh_init+0x430/0x7e0<br /> mlxsw_sp_nexthop_type_init+0x212/0x960<br /> mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280<br /> mlxsw_sp_nexthop6_group_get+0x392/0x6a0<br /> mlxsw_sp_fib6_entry_create+0x46a/0xfd0<br /> mlxsw_sp_router_fib6_replace+0x1ed/0x5f0<br /> mlxsw_sp_router_fib6_event_work+0x10a/0x2a0<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Liberado por la tarea 154:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x43/0x70<br /> kmem_cache_free_bulk.part.0+0x1eb/0x5e0<br /> kvfree_rcu_bulk+0x1f2/0x260<br /> kfree_rcu_work+0x130/0x1b0<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Última creación de trabajo potencialmente relacionada:<br /> kasan_save_stack+0x30/0x50<br /> kasan_record_aux_stack+0x8c/0xa0<br /> kvfree_call_rcu+0x93/0x5b0<br /> mlxsw_sp_router_neigh_event_work+0x67d/0x860<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/xe: Limitar num_syncs para prevenir asignaciones de tamaño excesivo<br /> <br /> Las ioctl exec y vm_bind permiten al espacio de usuario especificar un valor num_syncs arbitrario. Sin comprobación de límites, un num_syncs muy grande puede forzar una asignación excesivamente grande, lo que lleva a advertencias del kernel del asignador de páginas como se muestra a continuación.<br /> <br /> Introducir DRM_XE_MAX_SYNCS (establecido en 1024) y rechazar cualquier solicitud que exceda este límite.<br /> <br /> &amp;#39;------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124<br /> ...<br /> Call Trace:<br /> <br /> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416<br /> ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317<br /> __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348<br /> __do_kmalloc_node mm/slub.c:4364 [inline]<br /> __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388<br /> kmalloc_noprof include/linux/slab.h:909 [inline]<br /> kmalloc_array_noprof include/linux/slab.h:948 [inline]<br /> xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158<br /> drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797<br /> drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894<br /> xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:598 [inline]<br /> __se_sys_ioctl fs/ioctl.c:584 [inline]<br /> __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...&amp;#39;<br /> <br /> v2: Añadir &amp;#39;Reported-by&amp;#39; y Cc kernels estables.<br /> v3: Cambiar XE_MAX_SYNCS de 64 a 1024. (Matt y Ashutosh)<br /> v4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt)<br /> v5: Realizar la comprobación al principio de la función exec. (Matt)<br /> <br /> (cherry picked from commit b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> NFSD: la creación de archivos NFSv4 omite establecer la ACL<br /> <br /> Un cliente NFSv4 que establece una ACL con un principal nombrado durante la creación del archivo recupera la ACL después, y encuentra que es solo una ACL predeterminada (basada en los bits de modo) y no la ACL que fue solicitada durante la creación del archivo. Esto viola la sección 6.4.1.3 de RFC 8881: &amp;#39;el atributo ACL se establece tal como se proporciona&amp;#39;.<br /> <br /> El problema ocurre en nfsd_create_setattr(), que llama a nfsd_attrs_valid() para determinar si llamar a nfsd_setattr(). Sin embargo, nfsd_attrs_valid() verifica solo los cambios de iattr y las etiquetas de seguridad, pero no las ACL de POSIX. Cuando solo una ACL está presente, la función devuelve falso, nfsd_setattr() es omitida, y la ACL de POSIX nunca se aplica al inodo.<br /> <br /> Posteriormente, cuando el cliente recupera la ACL, el servidor no encuentra ninguna ACL de POSIX en el inodo y devuelve una generada a partir de los bits de modo del archivo en lugar de devolver la ACL especificada originalmente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> platform/chrome: cros_ec_ishtp: Corrección de UAF tras desvincular el controlador<br /> <br /> Después de desvincular el controlador, otro kthread &amp;#39;cros_ec_console_log_work&amp;#39; sigue accediendo al dispositivo, lo que resulta en un UAF y un fallo.<br /> <br /> El controlador no anula el registro del dispositivo EC en .remove(), lo que debería apagar los subdispositivos de forma síncrona. Corregido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fuse: corrige la corrupción de la lista de io-uring para solicitudes terminadas no confirmadas<br /> <br /> Cuando una solicitud es terminada antes de que haya sido confirmada, la solicitud no es eliminada de la lista de la cola. Esto deja una entrada de lista colgante que lleva a la corrupción de la lista y a problemas de uso después de liberación.<br /> <br /> Eliminar la solicitud de la lista de la cola para solicitudes terminadas no confirmadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: corrige la validación del búfer al incluir el tamaño del terminador nulo en la longitud de EA<br /> <br /> La función smb2_set_ea, que maneja los Atributos Extendidos (EA),<br /> estaba realizando comprobaciones de validación del búfer que omitían incorrectamente el tamaño<br /> del carácter de terminación nula (+1 byte) para el Nombre de EA.<br /> Este parche corrige el problema al añadir explícitamente &amp;#39;+ 1&amp;#39; a EaNameLength donde<br /> se espera que el terminador nulo esté presente en el búfer, asegurando<br /> que la validación refleje con precisión el tamaño total de búfer requerido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> block: corrige la condición de carrera entre wbt_enable_default y el envío de E/S<br /> <br /> Cuando wbt_enable_default() se mueve fuera de la congelación de la cola en elevator_change(), puede hacer que el contador inflight de wbt se vuelva negativo (-1), lo que lleva a tareas colgadas en la ruta de writeback. Las tareas se quedan atascadas en wbt_wait() porque el contador está en un estado inconsistente.<br /> <br /> El problema ocurre porque wbt_enable_default() podría competir con el envío de E/S, permitiendo que el contador se decremente antes de la inicialización adecuada. Esto se manifiesta como:<br /> <br /> rq_wait[0]:<br /> inflight: -1<br /> has_waiters: True<br /> <br /> rwb_enabled() verifica el estado, que puede actualizarse exactamente entre wbt_wait() (rq_qos_throttle()) y wbt_track()(rq_qos_track()), entonces el contador inflight se volverá negativo.<br /> <br /> Y resulta en advertencias de tareas colgadas como:<br /> task:kworker/u24:39 state:D stack:0 pid:14767<br /> Call Trace:<br /> rq_qos_wait+0xb4/0x150<br /> wbt_wait+0xa9/0x100<br /> __rq_qos_throttle+0x24/0x40<br /> blk_mq_submit_bio+0x672/0x7b0<br /> ...<br /> <br /> Esto se soluciona mediante:<br /> <br /> 1. Dividiendo wbt_enable_default() en:<br /> - __wbt_enable_default(): Devuelve verdadero si se debe llamar a wbt_init()<br /> - wbt_enable_default(): Envoltorio para las funciones que ya lo llaman (sin inicialización)<br /> - wbt_init_enable_default(): Nueva función que verifica e inicializa WBT<br /> <br /> 2. Usando wbt_init_enable_default() en blk_register_queue() para asegurar una inicialización adecuada durante el registro de la cola<br /> <br /> 3. Moviendo wbt_init() fuera de wbt_enable_default(), que es solo para habilitar wbt deshabilitado de bfq e iocost, y wbt_init() no es necesario. Así se puede evitar la advertencia de bloqueo original.<br /> <br /> 4. Eliminando la bandera ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT y su código de manejo, ya que ya no es necesario<br /> <br /> Esto asegura que WBT se inicialice correctamente antes de que se pueda enviar cualquier E/S, evitando que el contador se vuelva negativo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: vidtv: inicializar punteros locales tras la transferencia de la propiedad de la memoria<br /> <br /> vidtv_channel_si_init() crea una lista temporal (programa, servicio, evento) y la propiedad de la memoria misma se transfiere a las tablas PAT/SDT/EIT a través de vidtv_psi_pat_program_assign(), vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().<br /> <br /> El problema aquí es que el puntero local donde se completó la transferencia de la propiedad de la memoria no se inicializa a NULL. Esto hace que la función vidtv_psi_pmt_create_sec_for_each_pat_entry() falle, y en el flujo que salta a free_eit, la memoria que fue liberada por vidtv_psi_*_table_destroy() puede ser accedida de nuevo por vidtv_psi_*_event_destroy() debido al puntero local no inicializado, por lo que se libera una vez más.<br /> <br /> Por lo tanto, para prevenir la vulnerabilidad de uso después de liberación y doble liberación, los punteros locales deben inicializarse a NULL al transferir la propiedad de la memoria.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tpm2-sessions: Corrección de indexación fuera de rango en name_size<br /> <br /> &amp;#39;name_size&amp;#39; no tiene ninguna comprobación de rango, y simplemente indexa directamente con TPM_ALG_ID, lo que podría llevar a corrupción de memoria en el peor de los casos.<br /> <br /> Abordar el problema procesando solo valores conocidos y devolviendo -EINVAL para valores no reconocidos.<br /> <br /> Hacer también &amp;#39;tpm_buf_append_name&amp;#39; y &amp;#39;tpm_buf_fill_hmac_session&amp;#39; falibles para que los errores sean detectados antes de causar cualquier tráfico TPM espurio.<br /> <br /> Finalizar también la sesión de autorización en caso de fallo en ambas funciones, ya que el estado de la sesión estaría entonces por definición corrupto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdgpu: soluciona una condición de carrera de acceso a job-&amp;gt;pasid en la recuperación de la GPU<br /> <br /> Evita un posible UAF en la recuperación de la GPU debido a una condición de carrera entre el callback de tiempo de espera de sched y la cola de trabajo tdr.<br /> <br /> La función de recuperación de la GPU llama a drm_sched_stop() y luego a drm_sched_start(). drm_sched_start() reinicia la cola tdr que eventualmente liberará el trabajo (job). Si la cola tdr libera el trabajo (job) antes de que el callback de tiempo de espera se complete, el trabajo (job) será liberado y obtendremos un UAF al acceder al pasid. Almacenarlo en caché con antelación para evitar el UAF.<br /> <br /> Ejemplo de traza KASAN:<br /> [ 493.058141] ERROR: KASAN: uso-después-de-liberación de slab en amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.067530] Lectura de tamaño 4 en la dirección ffff88b0ce3f794c por la tarea kworker/u128:1/323<br /> [ 493.074892]<br /> [ 493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G E 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntario)<br /> [ 493.076493] Tainted: [E]=UNSIGNED_MODULE<br /> [ 493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019<br /> [ 493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]<br /> [ 493.076512] Traza de Llamada:<br /> [ 493.076515] <br /> [ 493.076518] dump_stack_lvl+0x64/0x80<br /> [ 493.076529] print_report+0xce/0x630<br /> [ 493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0<br /> [ 493.076541] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.077253] kasan_report+0xb8/0xf0<br /> [ 493.077258] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.078672] ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu]<br /> [ 493.079378] ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu]<br /> [ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu]<br /> [ 493.080903] ? pick_task_fair+0x24e/0x330<br /> [ 493.080910] ? __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu]<br /> [ 493.081702] ? _raw_spin_lock+0x75/0xc0<br /> [ 493.081708] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched]<br /> [ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 493.081725] process_one_work+0x679/0xff0<br /> [ 493.081732] worker_thread+0x6ce/0xfd0<br /> [ 493.081736] ? __pfx_worker_thread+0x10/0x10<br /> [ 493.081739] kthread+0x376/0x730<br /> [ 493.081744] ? __pfx_kthread+0x10/0x10<br /> [ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 493.081751] ? __pfx_kthread+0x10/0x10<br /> [ 493.081755] ret_from_fork+0x247/0x330<br /> [ 493.081761] ? __pfx_kthread+0x10/0x10<br /> [ 493.081764] ret_from_fork_asm+0x1a/0x30<br /> [ 493.081771] <br /> <br /> (seleccionado de la confirmación 20880a3fd5dd7bca1a079534cf6596bda92e107d)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iomap: ajustar el rango de lectura correctamente para posiciones no alineadas a bloques<br /> <br /> iomap_adjust_read_range() asume que la posición y la longitud pasadas están alineadas a bloques. Sin embargo, este no siempre es el caso, como se muestra en el caso generado por syzbot para erofs. Esto causa que se salten demasiados bytes para bloques actualizados, lo que resulta en la devolución de una posición y longitud incorrectas para leer. Si todos los bloques están actualizados, esto provoca un desbordamiento negativo de la longitud y devuelve una posición más allá del folio.<br /> <br /> Corregir el cálculo para también tener en cuenta el desplazamiento del bloque al calcular cuántos bytes pueden ser saltados para bloques actualizados.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ethtool: Evitar el desbordamiento del búfer del espacio de usuario en la consulta de estadísticas<br /> <br /> El comando ethtool -S opera a través de tres llamadas ioctl:<br /> ETHTOOL_GSSET_INFO para el tamaño, ETHTOOL_GSTRINGS para los nombres, y<br /> ETHTOOL_GSTATS para los valores.<br /> <br /> Si el número de estadísticas cambia entre estas llamadas (p. ej., debido a la<br /> reconfiguración del dispositivo), la asignación de búfer del espacio de usuario será incorrecta,<br /> lo que podría llevar a un desbordamiento de búfer.<br /> <br /> Generalmente se espera que los controladores mantengan recuentos de estadísticas estables, pero algunos<br /> controladores (p. ej., mlx5, bnx2x, bna, ksz884x) usan contadores dinámicos, haciendo<br /> posible este escenario.<br /> <br /> Algunos controladores intentan manejar esto internamente:<br /> - bnad_get_ethtool_stats() retorna temprano en caso de que stats.n_stats no sea<br /> igual al recuento de estadísticas del controlador.<br /> - micrel/ksz884x también se asegura de no escribir nada más allá de<br /> stats.n_stats y desbordar el búfer.<br /> <br /> Sin embargo, ambos usan stats.n_stats que ya está asignado con el valor<br /> retornado de get_sset_count(), por lo tanto, no resolverá el problema descrito<br /> aquí.<br /> <br /> Cambiar ethtool_get_strings(), ethtool_get_stats(),<br /> ethtool_get_phy_stats() para no retornar nada en caso de una discrepancia<br /> entre el tamaño del espacio de usuario y get_sset_size(), para prevenir el desbordamiento de búfer.<br /> El valor n_stats retornado será igual a cero, para reflejar que<br /> no se ha retornado nada.<br /> <br /> Esto podría resultar en uno de dos casos al usar ethtool upstream,<br /> dependiendo de cuándo se detecte el cambio de tamaño:<br /> 1. Cuando se detecta en ethtool_get_strings():<br /> # ethtool -S eth2<br /> no hay estadísticas disponibles<br /> <br /> 2. Cuando se detecta en la obtención de estadísticas, todas las estadísticas se reportarán como cero.<br /> <br /> Ambos casos son presumiblemente transitorios, y una llamada ethtool subsiguiente<br /> debería tener éxito.<br /> <br /> Aparte de la evitación del desbordamiento, estos dos casos son muy evidentes (sin<br /> salida/estadísticas borradas), lo cual es posiblemente mejor que presentar<br /> estadísticas incorrectas/desplazadas.<br /> También consideré retornar un error en lugar de una respuesta &amp;#39;silenciosa&amp;#39;, pero<br /> eso parece más destructivo para las aplicaciones del espacio de usuario.<br /> <br /> Notas:<br /> - Este parche no pretende corregir la condición de carrera inherente, solo se asegura<br /> de que no desbordemos el búfer del espacio de usuario, y proporciona un comportamiento<br /> más predecible.<br /> <br /> - El bloqueo RTNL se mantiene durante cada ioctl, la ventana de carrera existe entre<br /> las llamadas ioctl separadas cuando se libera el bloqueo.<br /> <br /> - ethtool del espacio de usuario siempre llena stats.n_stats, pero es probable que<br /> estas ioctls de estadísticas estén implementadas en otras aplicaciones del espacio de usuario<br /> que podrían no llenarlo. El código añadido verifica que no sea cero,<br /> para prevenir cualquier regresión.