Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: uprobes: Añadir un archivo "fence.i" faltante tras la construcción del búfer XOL. El búfer XOL (ejecución fuera de línea) se utiliza para ejecutar paso a paso las instrucciones reemplazadas para uprobes. El puerto RISC-V carecía de un archivo "fence.i" adecuado (vaciado de i$) tras la construcción del búfer XOL, lo que puede provocar la ejecución incorrecta de instrucciones obsoletas o dañadas. Esto se detectó al ejecutar las pruebas automáticas de BPF "test_progs: uprobe_autoattach, attached_probe" en Spacemit K1/X60, donde las pruebas de uprobes fallaron aleatoriamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: hfsc: Se corrige también un posible UAF en hfsc_dequeue(). Al igual que en el parche anterior, también debemos proteger hfsc_dequeue(). Sin embargo, para este caso, no contamos con un reproductor fiable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrige la desreferencia del puntero NULL en tipc_mon_reinit_self() syzbot informó: tipc: Número de nodo establecido en 1055423674 Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 No contaminado 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Nombre del hardware: QEMU PC estándar (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Cola de trabajo: eventos tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [en línea] subproceso_de_trabajo+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_de_bifurcación+0x45/0x80 arch/x86/kernel/process.c:153 ret_de_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 00000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Hay una condición de ejecución entre la cola de trabajo creada al habilitar el portador y otro hilo creado al deshabilitar el portador justo después de eso, como se muestra a continuación: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: se corrige el acceso fuera de los límites en nvmet_enable_port Al intentar habilitar un puerto que aún no tiene transporte configurado, nvmet_enable_port() usa NVMF_TRTYPE_MAX (255) para consultar la matriz de transportes, lo que provoca un acceso fuera de los límites: [ 106.058694] ERROR: KASAN: global fuera de los límites en nvmet_enable_port+0x42/0x1da [ 106.058719] Lectura de tamaño 8 en la dirección ffffffff89dafa58 por la tarea ln/632 [...] [ 106.076026] nvmet: no se admite el tipo de transporte 255 Desde la confirmación 200adac75888, NVMF_TRTYPE_MAX es el estado predeterminado según la configuración de nvmet_ports_make(). Evite esto verificando NVMF_TRTYPE_MAX antes de continuar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Añadir comprobación de valores nulos en ufshcd_mcq_compl_pending_transfer(). Añadir una comprobación de valores nulos para el puntero hwq devuelto por ufshcd_mcq_req_to_hwq(). Esto es similar a la corrección en el commit 74736103fb41 ("scsi: ufs: core: Corregir el problema de ejecuciones de ufshcd_abort_one").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: return EIO on RAID1 block group write pointer mismatch Hubo un informe de error sobre una desreferencia de puntero NULL en __btrfs_add_free_space_zoned() que en última instancia ocurre debido a una conversión del perfil de metadatos predeterminado DUP a un perfil RAID1 en dos discos. El seguimiento de la pila tiene la siguiente firma: Error BTRFS (dispositivo sdc): zoned: desajuste del desplazamiento del puntero de escritura de las zonas en el perfil raid1 ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000058 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ fin del seguimiento 000000000000000 ]--- La primera línea es la más interesante aquí: Error BTRFS (dispositivo sdc): zoned: discrepancia en el desplazamiento del puntero de escritura de las zonas en el perfil RAID1. Cuando se crea un grupo de bloques RAID1 y se detecta una discrepancia en el desplazamiento del puntero de escritura entre los discos del conjunto RAID, btrfs establece el valor de alloc_offset en la longitud del grupo de bloques, marcándolo como lleno. Posteriormente, el código espera que una operación de balance evacue los datos de este grupo de bloques y solucione los problemas. Sin embargo, antes de que esto sea posible, el nuevo espacio de este grupo de bloques se contabilizará en la caché de espacio libre. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/eevdf: Se soluciona que se->slice se establezca en U64_MAX y el bloqueo resultante Hay una ruta de código en dequeue_entities() que puede establecer el slice de un sched_entity en U64_MAX, lo que a veces resulta en un bloqueo. El caso ofensivo es cuando se llama a dequeue_entities() para sacar de la cola una entidad de grupo retrasada y luego se retrasa la salida de la cola del padre de la entidad. En ese caso: 1. En el bloque if (entity_is_task(se)) else al comienzo de dequeue_entities(), slice se establece en cfs_rq_min_slice(group_cfs_rq(se)). Si la entidad se retrasó, entonces no tiene tareas en cola, por lo que cfs_rq_min_slice() devuelve U64_MAX. 2. El primer bucle for_each_sched_entity() saca de la cola la entidad. 3. Si la entidad era la única hija de su padre, la siguiente iteración intenta sacar de la cola al padre. 4. Si es necesario retrasar la salida de la cola del padre, se interrumpe desde el primer bucle for_each_sched_entity() _sin actualizar la porción_. 5. El segundo bucle for_each_sched_entity() establece la porción -> del padre en la porción guardada, que sigue siendo U64_MAX. Esto altera los cálculos posteriores con resultados potencialmente catastróficos. Una manifestación que vimos en producción fue: 6. En update_entity_lag(), se->slice se usa para calcular el límite, que termina como un número negativo enorme. 7. limit se usa en se->vlag = clamp(vlag, -limit, limit). Como limit es negativo, vlag > limit, por lo que se->vlag se establece en el mismo número negativo enorme. 8. En place_entity(), se->vlag se escala, lo que se desborda y da como resultado otro número enorme (positivo o negativo). 9. El retardo ajustado se resta de se->vruntime, lo que aumenta o disminuye se->vruntime considerablemente. 10. pick_eevdf() llama a entity_eligible()/vruntime_eligible(), que devuelve incorrectamente "false" debido a la gran distancia entre el vruntime y los demás vruntimes de la cola, lo que provoca un desbordamiento del cálculo de carga (vruntime - cfs_rq->min_vruntime) *. 11. Nada parece ser elegible, por lo que pick_eevdf() devuelve NULL. 12. pick_next_entity() intenta desreferenciar el valor de retorno de pick_eevdf() y se bloquea. Volcar los estados de cfs_rq desde los volcados de núcleo con drgn mostró rangos de tiempo de ejecución virtuales enormes y valores de vlag falsos, y también rastreé que se->slice se configuraba en U64_MAX en sistemas en vivo (lo cual solía ser "benigno", ya que el resto de la cola de ejecución debía estar en un estado específico para fallar). Corríjalo en dequeue_entities() configurando siempre slice desde el primer cfs_rq no vacío.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v2m: Impedir el uso tras la liberación de gicv2m_get_fwnode() Con ACPI en su lugar, gicv2m_get_fwnode() se registra en el subsistema pci como pci_msi_get_fwnode_cb(), que puede invocarse en tiempo de ejecución durante un sondeo de puente de host PCI. Pero, la devolución de llamada se marca erróneamente como __init, lo que provoca que se libere, mientras se registra en el subsistema PCI y podría desencadenar: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 Esto es fácilmente reproducible en una placa Juno con arranque ACPI. Conserve la función para uso posterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: class: Fix. Acceso a punteros nulos. Las llamadas simultáneas a typec_partner_unlink_device pueden provocar una desreferencia de punteros nulos. Este parche añade un mutex para proteger los punteros de dispositivos USB y evitar este problema. Este mismo mutex protege tanto los punteros de dispositivo como el registro del dispositivo asociado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: comprobar que el recuento de eventos no supere la longitud del búfer de eventos. El recuento de eventos se lee del registro DWC3_GEVNTCOUNT. Se comprueba que el recuento sea cero, pero no que supere la longitud del búfer de eventos. Se comprueba que el recuento de eventos no supere la longitud del búfer de eventos, lo que evita un acceso fuera de los límites al copiar el evento a memoria. Registro de fallos: No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Rastreo de llamadas: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: ci_hdrc_imx: corrección del manejo de usbmisc. usbmisc es una propiedad opcional del dispositivo, por lo que es totalmente válido que el valor correspondiente de data->usbmisc_data sea nulo. Verifique esto antes de desreferenciar el puntero. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdns3: Corrección de interbloqueo al usar el gadget NCM. El controlador cdns3 presenta el mismo interbloqueo NCM corregido en cdnsp mediante el commit 58f2fcb3a845 ("usb: cdnsp: Corrección de un problema de interbloqueo durante el uso del gadget NCM"). Bajo PREEMPT_RT, el interbloqueo puede activarse fácilmente por tráfico de red intenso, por ejemplo, al usar "iperf --bidir" a través de un enlace Ethernet NCM. El interbloqueo se produce porque el manejador de interrupciones en subprocesos es interrumpido por un softirq, pero ambos están protegidos por el mismo bloqueo de giro. Para evitar el interbloqueo, desactive el softirq durante el controlador de interrupciones en subprocesos.