Vulnerabilidades

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: bpf, sockmap: Se corrige más mensajes sin cargar mientras msg tiene more_data En tcp_bpf_send_verdict(), si msg tiene más datos después de tcp_bpf_sendmsg_redir(): tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 caso __SK_REDIRECT: sk_msg_return() //mensaje sin cargar->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //después de tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 caso __SK_REDIRECT: sk_msg_return() //msg->sg.size(11000) no cargado a sk->sk_forward_alloc El msg->sg.size(11000) se ha descargado dos veces, para solucionarlo podemos cargar el msg->sg.size restante antes de ir a más datos. Este problema puede generar la siguiente información: ADVERTENCIA: CPU: 0 PID: 9860 en net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Seguimiento de llamadas: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 ? vfs_write+0x237/0x290 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae ADVERTENCIA: CPU: 0 PID: 2136 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Rastreo de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/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: bpf, sockmap: Se corrige la doble descarga de la memoria de sk_msg. Si tcp_bpf_sendmsg se está ejecutando durante una operación de desmantelamiento, psock puede liberarse. tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() Unlikely(!psock)) sk_msg_free() La memoria de msg ha sido descargada en tcp_bpf_send_verdict() por sk_msg_return(), y sería descargada nuevamente por sk_msg_free(). Cuando psock es nulo, podemos simplemente devolver un código de error, esto activaría sk_msg_free_nocharge en la ruta de error de __SK_REDIRECT y tendría el efecto secundario de arrojar un error al espacio del usuario. Esto sería un ligero cambio en el comportamiento del lado del usuario, pero se vería igual que un error si la redirección en el socket arrojara un error. Este problema puede causar la siguiente información: ADVERTENCIA: CPU: 0 PID: 2136 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Seguimiento de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/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/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: 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: bcmgenet: Use lecturas/escrituras de registros más fuertes para asegurar el orden GCC12 parece ser mucho más inteligente sobre su seguimiento de dependencias y es consciente de que las variantes relajadas son solo cargas y almacenamientos normales y esto está causando problemas como: [ 210.074549] ------------[ cortar aquí ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): se agotó el tiempo de espera de la cola de transmisión 1 [ 210.086717] ADVERTENCIA: CPU: 1 PID: 0 en net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Módulos vinculados en: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 CPPC ACPI: el canal de verificación de PCC falló para ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Contaminado: GE 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: no se pudieron leer los contadores de rendimiento [ 210.161349] Nombre del hardware: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ [210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc: dev_watchdog+0x234/0x240 [210.161364] lr: dev_watchdog+0x234/0x240 [210.161368] sp: ffff8000080a3a40 [210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9: ffffcd4258bdad9c [210.248171] x8: 00000000ffffdfff x7: 000000000000003f x6: 0000000000000000 [210.255341] x5: 0000000000000000 x4 : 0000000000000000 x3 : 00000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Rastreo de llamadas: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 La suposición cuando se relajaron estos parece ser que la memoria del dispositivo se asignaría sin reordenamiento, y que otras construcciones (spinlocks/etc) proporcionaría las barreras para asegurar que los datos de los paquetes y los anillos/colas en memoria se ordenaran con respecto a las lecturas/escrituras de los registros del dispositivo. Esto en sí mismo parece un poco impreciso, pero el problema real con GCC12 es que está moviendo las lecturas/escrituras reales a voluntad como si fueran operaciones independientes cuando en realidad no lo son, pero el compilador no puede saberlo. Al observar los volcados de ensamblaje para muchas de estas rutinas, es posible ver operaciones muy limpias, pero no estrictamente en el orden del programa, que ocurren como el compilador podría hacer si no fueran operaciones de lectura/escritura de registros en realidad. Es posible suprimir el tiempo de espera con un poco de dma_mb() esparcidos por ahí, pero el dispositivo todavía parece incapaz de enviar/recibir datos de manera confiable. Un mejor plan es usar el readl/writel más seguro en todas partes. Dado que esto revierte parcialmente una confirmación anterior, que señala el uso de las variantes relajadas por razones de rendimiento. ---truncado---

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.