Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Se corrige la pérdida de memoria en el flujo de error para la rutina de evento de suscripción. En caso de que falle el segundo xa_insert(), no se libera el obj_event. Corrija el flujo de desenrollado de error para liberar esa memoria y evitar una pérdida de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Corregir pérdida de memoria en sk_psock_queue_msg Si tcp_bpf_sendmsg se está ejecutando durante una operación de desmontaje, podemos poner en cola datos en la cola de mensajes de entrada mientras el desmontaje intenta liberarlos. sk1 (redireccionar sk2) sk2 ------------------- --------------- tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... bloqueando sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock() Mientras se usa drop_sk_msg(), el mensaje ha cargado la memoria del formulario sk mediante sk_mem_charge y tiene páginas sg que se deben colocar. Para solucionarlo, usamos sk_msg_free() y luego kfee() msg. Este problema puede causar la siguiente información: ADVERTENCIA: CPU: 0 PID: 9202 en net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0 Rastreo de llamadas: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0 Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/irdma: Evitar algunos desbordamientos de enteros Mi verificador estático se queja de que: drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init() warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'? Parece que "info->dev->hmc_fpm_misc.max_ceqs" proviene del firmware en irdma_sc_parse_fpm_query_buf() así que, sí, existe la posibilidad de que sea cero. Incluso si confiamos en el firmware, es bastante fácil cambiar la condición como una medida de endurecimiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: se corrige la ejecución entre xmit y reset Existe una ejecución entre reset y las rutas de transmisión que puede provocar que ibmvnic_xmit() acceda a un scrq después de que se haya liberado en la ruta de reset. Puede provocar un bloqueo como: El kernel intentó leer la página del usuario (0): ¿intento de explotación? (uid: 0) ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000000 Dirección de instrucción con error: 0xc0080000016189f8 Oops: Acceso del kernel al área defectuosa, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Rastreo de llamadas: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (no confiable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [enlace] [c008000002db8378] bond_start_xmit+0x40/0xc0 [enlace] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupción: 900 La causa inmediata del bloqueo es el acceso a tx_scrq en el siguiente fragmento durante un reinicio, donde tx_scrq puede ser NULL o una dirección que pronto será inválida: ibmvnic_xmit() { ... tx_scrq = adaptador->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } Pero más allá de eso, la llamada a ibmvnic_xmit() en sí no es segura durante un reinicio y la ruta de reinicio intenta evitar esto deteniendo la cola en ibmvnic_cleanup(). Sin embargo, justo después de que se detuviera la cola, una ibmvnic_complete_tx() en curso podría haber reiniciado la cola incluso mientras el reinicio estaba en progreso. Dado que la cola se reinició, podríamos recibir una llamada a ibmvnic_xmit() que luego puede acceder al tx_scrq incorrecto (u otros campos). Sin embargo, no podemos simplemente hacer que ibmvnic_complete_tx() verifique el bit ->resetting y omita el inicio de la cola. Esto puede funcionar en el "back-end" de un reinicio correcto que simplemente reinició la cola pero aún no borró el bit ->resetting. Si omitimos el reinicio de la cola debido a que ->resetting es verdadero, la cola permanecería detenida indefinidamente, lo que podría provocar tiempos de espera de transmisión. IOW ->resetting es demasiado amplio para este propósito. En su lugar, use un nuevo indicador que indique si las colas están activas o no. Solo las rutas de apertura/reinicio controlan cuándo están activas las colas. ibmvnic_complete_tx() y otros activan la cola solo si la cola está marcada como activa. Por lo tanto, tendremos: A. restablecer/abrir subproceso en ibmvnic_cleanup() y __ibmvnic_open() ->resetting = true ->tx_queues_active = false deshabilitar colas de transmisión ... ->tx_queues_active = true iniciar colas de transmisión B. Interrupción de transmisión en ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); Para garantizar que ->tx_queues_active y el estado de las colas sean cons ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Arreglar doble liberación durante el reinicio de la GPU en flujos de DC [Por qué] El problema solo ocurre durante la ruta del código de reinicio de la GPU. Primero hacemos una copia de seguridad del estado actual antes de confirmar 0 flujos internamente desde DM a DC. Esta copia de seguridad del estado contiene asignaciones de codificador de enlace válidas. DC borrará las asignaciones de codificador de enlace como parte del estado actual (pero no la copia de seguridad, ya que se copió antes de el commit) y liberará la referencia de flujo adicional que tenía. DC requiere que las asignaciones de codificador de enlace permanezcan borradas/inválidas antes de el commit. Dado que la copia de seguridad aún tiene asignaciones válidas, llamamos a la interfaz post reset para borrarlas. Esta rutina también libera la referencia adicional que tenía la interfaz de codificador de enlace, lo que da como resultado una doble liberación (y eventualmente una desreferencia de puntero NULL). [Cómo] Tendremos que hacer una confirmación de DC completa de todos modos después de reiniciar la GPU porque el conteo de transmisiones anteriormente llegó a 0. No necesitamos conservar la asignación que habíamos respaldado, así que simplemente copiamos la asignación del estado actual ahora limpio después de que se haya producido el reinicio con la nueva interfaz link_enc_cfg_copy().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kernel/resource: fix kfree() of bootmem memory again Desde el commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory"), podríamos obtener un recurso asignado durante el arranque a través de alloc_resource(). Y es necesario liberar el recurso utilizando free_resource(). Sin embargo, muchas personas utilizan kfree directamente, lo que dará como resultado un ERROR del kernel. Para solucionar esto sin reparar cada sitio de llamada, simplemente filtre un par de bytes en ese caso especial.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mxser: se corrige la fuga de xmit_buf en activate cuando LSR == 0xff Cuando LSR es 0xff en ->activate() (bastante diferente), devolvemos un error. Siempre que no se llame a ->shutdown() cuando ->activate() falla, en realidad nada libera el búfer en este caso. Corrija esto liberando correctamente el búfer en una etiqueta designada. Saltamos allí también desde "!info->type" if now también.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: ethernet: cpsw: fix panic when interrumpe coaleceing is seted via ethtool cpsw_ethtool_begin directamente devuelve el resultado de pm_runtime_get_sync cuando es exitoso. pm_runtime_get_sync devuelve el código de error en caso de fallo y 0 en caso de reanudación exitosa, pero también 1 cuando el dispositivo ya está activo. Por lo tanto, el caso común para cpsw_ethtool_begin es devolver 1. Eso lleva a llamadas inconsistentes a pm_runtime_put en la cadena de llamadas, de modo que pm_runtime_put se llama una vez de más y, como resultado, deja suspendido el cpsw dev. El cpsw dev suspendido lleva a una violación de acceso más adelante por diferentes partes del controlador cpsw. Solucione esto llamando a la función pm_runtime_resume_and_get, que es amigable con los retornos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: fix 'scheduling while atomic' on aux critical err interrupción Hay un ERROR del kernel en el procesamiento de interrupciones de error crítico auxiliar en ice_misc_intr(): [ 2100.917085] ERROR: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Seguimiento de llamadas: [ 2101.063229] [ 2101.065252] dump_stack+0x41/0x60 [ 2101.068587] __schedule_bug.cold.100+0x4c/0x58 [ 2101.073060] __schedule+0x6a4/0x830 [ [2101.076570] schedule+0x35/0xa0 [2101.079727] schedule_preempt_disabled+0xa/0x10 [2101.084284] __mutex_lock.isra.7+0x310/0x420 [2101.088580] ? ice_misc_intr+0x201/0x2e0 [hielo] [ 2101.093078] ice_send_event_to_aux+0x25/0x70 [hielo] [ 2101.097921] ice_misc_intr+0x220/0x2e0 [hielo] [ 2101.102232] __handle_irq_event_percpu+0x40/0x180 [ 2101.106965] handle_irq_event_percpu+0x30/0x80 [ 2101.111434] handle_irq_event+0x36/0x53 [ 2101.115292] handle_edge_irq+0x82/0x190 [ 2101.119148] handle_irq+0x1c/0x30 [ 2101.122480] do_IRQ+0x49/0xd0 [ 2101.125465] common_interrupt+0xf/0xf [ 2101.129146] ... Como Andrew mencionó correctamente anteriormente[0], ocurre la siguiente escalera de llamadas: ice_misc_intr() <- hardirq ice_send_event_to_aux() device_lock() mutex_lock() might_sleep() might_resched() <- oops Agregue un nuevo bit de estado de PF que indique que ocurrió un error crítico auxiliar y sirvalo en ice_service_task() en el contexto del proceso. El nuevo ice_pf::oicr_err_reg es de lectura y escritura tanto en contextos de hardirq como de proceso, pero solo 3 bits de datos no críticos probablemente no merezcan una sincronización explícita (e incluso están en el mismo byte [31:24]). [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: fix panic on shutting if multi-chip tree failed to probe El sondeo de DSA es atípico porque un árbol de dispositivos debe sondear todos a la vez, por lo que de N switches que llaman a dsa_tree_setup_routing_table() durante el sondeo, para (N - 1) de ellos, "complete" devolverá false y saldrán del sondeo antes de tiempo. El Nth switch configurará todo el árbol en su nombre. La implicación es que para (N - 1) switches, el controlador se vincula al dispositivo con éxito, sin hacer nada. Cuando el controlador está vinculado, el método ->shutdown() puede ejecutarse. Pero si el Nth switch no ha podido inicializar el árbol, no hay nada que hacer para las (N - 1) instancias del controlador, ya que los dispositivos esclavos no se han creado, etc. Además, dsa_switch_shutdown() espera que el @ds que llama se haya inicializado de hecho, por lo que salta a desreferenciar las diversas estructuras de datos, lo cual es incorrecto. Evite las desreferencias de puntero NULL resultantes simplemente verificando si el conmutador Nth ha establecido previamente "ds->setup = true" para el conmutador que se está apagando actualmente. La configuración completa está serializada bajo dsa2_mutex que ya tenemos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: Se corrige el uso después de liberar en remove_phb_dynamic() En remove_phb_dynamic() usamos &phb->io_resource, después de haber llamado a device_unregister(&host_bridge->dev). Pero la anulación del registro puede haber liberado a phb, porque pcibios_free_controller_deferred() es la función de liberación para host_bridge. Si no hay referencias pendientes cuando llamamos a device_unregister(), phb se liberará de nosotros. Esto ha pasado desapercibido, pero con slub_debug y page_poison habilitados puede provocar un bloqueo: PID: 7574 TAREA: c0000000d492cb80 CPU: 13 COMANDO: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt en c000000000008b30 Marco de excepción de acceso a datos SLB [380]: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 000000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 PIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Resultado de llamada al sistema: fffffffffffffff2 [NIP: release_resource+56] [LR: release_resource+48] #5 [c0000000e4f07a00] release_resource en c000000000167258 (no confiable) #6 [c0000000e4f07a30] remove_phb_dynamic en c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot en c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store en c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store en c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write en c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter en c00000000063d868 #12 [c0000000e4f07c70] new_sync_write en c00000000054339c #13 [c0000000e4f07d10] vfs_write en c000000000546624 #14 [c0000000e4f07d60] ksys_write en c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168 Para evitarlo, podemos tomar una referencia a host_bridge->dev hasta que terminemos de usar phb. Luego, cuando eliminemos la referencia, se liberará phb.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_netlink: Se corrige el cambio fuera de los límites en el cálculo de la máscara de grupo Cuando se recibe un mensaje netlink, netlink_recvmsg() completa la dirección del remitente. Uno de los campos es el campo de bits de 32 bits nl_groups, que lleva el grupo de multidifusión en el que se recibió el mensaje. El bit menos significativo corresponde al grupo 1 y, por lo tanto, el grupo más alto que el campo puede representar es 32. Por encima de eso, el depurador de UB marca los intentos de cambio fuera de los límites. Los bits que terminan siendo establecidos en tal caso están definidos por la implementación, pero será un valor incorrecto distinto de cero o cero, lo que al menos no es engañoso. Haga que la última opción sea determinista estableciendo siempre en 0 para los grupos de multidifusión de número superior. Para obtener información sobre la membresía en grupos >= 32, se espera que el espacio de usuario use los mensajes de control nl_pktinfo[0], que se habilitan mediante la opción de socket NETLINK_PKTINFO. [0] https://lwn.net/Articles/147608/ La forma de desencadenar este problema es, por ejemplo, a través del monitoreo del grupo BRVLAN: # bridge monitor vlan & # ip link add name br type bridge Lo que produce la siguiente cita: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'