Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/mediatek: habilite siempre clk al reanudar. En mtk_iommu_runtime_resume habilite siempre clk, incluso si m4u_dom es nulo. De lo contrario, el cb 'suspender' podría desactivar el clk que ya está desactivado provocando la advertencia: [1.586104] infra_m4u ya desactivado [1.586133] ADVERTENCIA: CPU: 0 PID: 121 en drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8 [ 1.594391] mtk-iommu 10205000.iommu: enlazado 18001000.larb (ops mtk_smi_larb_component_ops) [ 1.598108] Módulos vinculados en: [ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 No contaminado 5.12.0 -rc5 #69 [ 1.609246] mtk-iommu 10205000.iommu: enlazado 14027000.larb (ops mtk_smi_larb_component_ops) [ 1.617487] Nombre del hardware: Google Elm (DT) [ 1.617491] Cola de trabajo: pm pm_runtime_work [ 1.620545] mtk-iomm u 10205000.iommu: encuadernado 19001000.larb (ops mtk_smi_larb_component_ops) [1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [1.659297] pc: clk_core_disable+0xb0/0xb8 [1.663475] lr: clk_core_disable+0xb0/0x b8 [1.667652] sp: ffff800011b9bbe0 [ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000 [ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98 [ 1.681574] x25: ffff800011b9 bd48 x24: 0000000000000000 [ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90 [ 1.692189] x21: 0000000000000000a x20: ffff0000c004850 0 [1,697496] x19: ffff0000c0048500 x18: ffffffffffffffff [ 1.702804] x17: 0000000000000000 x16: 00000000000000000 [ 1.708112] x15: ffff800011460300 x14: ffffffffffe000 0 [ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720 [ 1.718727] x11: 0720072007200720 x10: 0720072007200720 [ 1.724035] x9 : ffff800 011b9bbe0 x8: ffff800011b9bbe0 [ 1.729342] x7: 0000000000000009 x6: ffff8000114b8328 [1.734649] x5: 0000000000000000 x4: 00000000000000000 [1.739956] x3: 00000000ffff ffff x2: ffff800011460298 [1.745263] x1: 1af1d7de276f4500 x0: 0000000000000000 [1.750572] Rastreo de llamadas: [1.753010] clk_core_disable+0xb0/0xb8 [ 1.756840] clk_core_disable_lock+0x24/0x40 [ 1.761105] clk_disable+0x20/0x30 [ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8 [ 1.769114] pm_generic_runtime_suspend+0x2c/0x48 [ 1 .773815] __rpm_callback+0xe0/0x178 [ 1.777559] rpm_callback+0x24/0x88 [ 1.781041] rpm_suspend+0xdc/0x470 [ 1.784523] rpm_idle+0x12c/0x170 [ 1.787831] pm_runtime_work+0xa8/0xc0 [ 1.791573] Process_one_work+0x1e8/0x360 [ 1.795580] trabajador_thread+0x44/0x478 [ 1.799237] kthread+0x150/0x158 [ 1.802460] ret_from_fork+ 0x10/0x30 [1.806034] ---[ final de seguimiento 82402920ef64573b ]--- [ 1.810728] ------------[ cortar aquí ]------------ Además , ahora no necesitamos habilitar el reloj desde la función mtk_iommu_hw_init ya que ya está habilitado en el currículum.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs-clt: destruye sysfs después de eliminar la sesión de la lista activa Una sesión se puede eliminar dinámicamente mediante la interfaz sysfs "remove_path" que eventualmente llama a la función rtrs_clt_remove_path_from_sysfs. El rtrs_clt_remove_path_from_sysfs actual primero elimina las interfaces sysfs y libera el objeto sess->stats. En segundo lugar, elimina la sesión de la lista activa. Por lo tanto, algunas funciones podrían acceder a sesiones no conectadas y acceder al objeto sess->stats liberado incluso si verifican el estado de la sesión antes de acceder a la sesión. Por ejemplo, rtrs_clt_request y get_next_path_min_inflight verifican el estado de la sesión e intentan enviar IO a la sesión. El estado de la sesión podría cambiarse cuando intentan enviar IO pero no pudieron detectar el cambio y actualizar la información estadística en el objeto sess->stats, y generar un problema de use-after-free. (ver: "RDMA/rtrs-clt: Verifique el estado de rtrs_clt_sess antes de leer sus estadísticas") Este parche cambia rtrs_clt_remove_path_from_sysfs para eliminar la sesión de la lista de sesiones activas y luego destruir las interfaces sysfs. Cada función aún debe verificar el estado de la sesión porque el cierre o las rutas de recuperación de errores pueden cambiar el estado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921: soluciona el fallo del kernel cuando no se puede descargar el firmware. Se soluciona el fallo del kernel cuando falta el firmware o no se puede descargar. [9.444758] ¡ERROR del kernel en drivers/pci/msi.c:375! [0 x40/ 0x184 [ 9.513893] sp : ffffffc015193870 [ 9.517194] x29: ffffffc015193870 x28: 00000000f0e94fa2 [ 9.522492] x27: 0000000000000acd x26: 000000 000000009a [ 9.527790] x25: ffffffc0152cee58 x24: ffffffdbb383e0d8 [ 9.533087] x23: ffffffdbb38628d0 x22: 0000000000040200 [ 9.538384] x21: ffffff8cf 7de7318 x20 : ffffff8cd65a2480 [ 9.543681] x19: ffffff8cf7de7000 x18: 0000000000000000 [ 9.548979] x17: ffffff8cf9ca03b4 x16: ffffffdc13ad9a34 [ 9.554277] x15: 00 00000000000000 x14: 0000000000080800 [ 9.559575] x13: ffffff8cd65a2980 x12: 00000000000000000 [ 9.564873] x11: ffffff8cfa45d820 x10: ffffff8cfa45 d6d0 [9.570171] X9: 000000000000000040 X8: FFFFFF8CCEF1B780 [9.575469] x7: aaaaaaaaaaaaaaaaa X6: 00000000000000000000 [9.580766] x5: fffffffdc13824900 x4: fffff8ce 00000000000000 x2: 000000000000000000 [9.591362] X1: 000000000000000125 X0: FFFFFFF8CCEFE0000 [9.596660] Llame Trace: [9.599095 ] free_msi_irqs+0x180/0x184 [ 9.602831] pci_disable_msi+0x100/0x130 [ 9.606740] pci_free_irq_vectors+0x24/0x30 [ 9.610915] mt7921_pci_probe+0xbc/0x250 [mt7921 e] [ 9.615693] pci_device_probe+0xd4/0x14c [ 9.619604] very_probe+0x134/0x2ec [ 9.623252] driver_probe_device+0x64/0xfc [ 9.627335] dispositivo_driver_attach+0x4c/0x6c [ 9.631506] __driver_attach+0xac/0xc0 [ 9.635243] bus_for_each_dev+0x8c/0xd4 [ 9.639066] driver_ adjuntar+0x2c/0x38 [ 9.642628] bus_add_driver+0xfc/0x1d0 [ 9.646365] driver_register+0x64/0xf8 [ 9.650101] __pci_register_driver+0x6c/0x7c [ 9.654360] init_module+0x28/0xfdc [mt7921e] [ 9.658704] do_one_initcall+0x13c/0x2d0 [ 9.662615] do_ módulo_init+0x58/0x1e8 [ 9.666351] módulo_carga+0xd80/0xeb4 [ 9.669912 ] __arm64_sys_finit_module+0xa8/0xe0 [ 9.674430] el0_svc_common+0xa4/0x16c [ 9.678168] el0_svc_compat_handler+0x2c/0x40 [ 9.682511] el0_svc_compat+0x8/0x10 [ 9.68 6076] Código: a94257f6 f9400bf7 a8c47bfd d65f03c0 (d4210000) [ 9.692155] ---[ fin trace 7621f966afbf0a29 ]--- [ 9.697385] Pánico del kernel: no se sincroniza: excepción grave [ 9.702599] SMP: detención de CPU secundarias [ 9.706549] Compensación del kernel: 0x1c03600000 de 0xffffffc010000000 [ 9.712456] PHYS_OFF CONJUNTO: 0xffffff440000000 [9.716625] Características de la CPU: 0x080026,2a80aa18 [ 9.720795] Límite de memoria: ninguno

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: mt7915: corrige informes txrate Verifique correctamente rate_info para corregir informes inesperados. [ 1215.161863] Rastreo de llamadas: [ 1215.164307] cfg80211_calculate_bitrate+0x124/0x200 [cfg80211] [ 1215.170139] ieee80211s_update_metric+0x80/0xc0 [mac80211] [ 1215.17562 4] ieee80211_tx_status_ext+0x508/0x838 [mac80211] [1215.181190] mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e] [ 1215.186580] mt7915_mac_tx_free+0x324/0x7c0 [mt7915e] [ 1215.191623] mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e] [ 1215.196582] mt76_dma_cleanup+0x7b 0/0x11d0 [mt76] [ 1215.201276] __napi_poll+0x38/0xf8 [ 1215.204668] napi_workfn+0x40/0x80 [ 1215.208062] proceso_one_work+0x1fc/0x390 [ 1215.212062] hilo_trabajador+0x48/0x4d0 [ 1215.215715] kthread+0x120/0x128 [ 1215.218935] ret_from_fork+0x10/0x1c

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: connac: corrige la advertencia del kernel agregando una interfaz de monitor. Corrija la siguiente advertencia del kernel agregando una interfaz de monitor en la rutina mt76_connac_mcu_uni_add_dev. [507.984882] ------------[ cortar aquí ]------------ [ 507.989515] ADVERTENCIA: CPU: 1 PID: 3017 en mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib ] [ 508.059379] CPU: 1 PID: 3017 Comm: ifconfig No contaminado 5.4.98 #0 [ 508.065461] Nombre de hardware: MT7622_MT7531 RFB (DT) [ 508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 508.074 939] ordenador personal : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib] [ 508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e] [ 508.087367] sp : ffffffc013a33930 [ 508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0 [ 508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008 [ 508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610 [ 508.106577] x23: ffffff801d022990 x22: ffffff801d024de8 [ 508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee 8 [ 508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000 [ 508.122482] x17: 00000000ffffffff x16: 00000000000000000 [ 508.127785] x15: 000 0000000000080 x14: ffffff801d704000 [ 508.133087] x13: 0000000000000040 x12: 0000000000000002 [ 508.138389] x11: 0000000000000000c x10: 0000000000000000 [ 508.143691] x9 : 0000000000000020 x8 : 0000000000000001 [ 508.148992] x7 : 0000000000000000 x6 : 00000000000000000 [ 508.154294] x5 : ffffff801c7eaee8 x4 : 00 00000000000006 [508.159596] x3: 0000000000000001 x2: 0000000000000000 [508.164898] x1: ffffff801c7eac08 x0: ffffff801d0226a0 [508.170200] Rastreo de llamadas: [508.172640] mt76_connac_mcu_uni_add_dev+0x178/0x1 90 [mt76_connac_lib] [508.179159] mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e] [508.184394] drv_add_interface+0x34/0x88 [mac80211 ] [ 508.189271] ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211] [ 508.195277] ieee80211_do_open+0x86c/0x918 [mac80211] [ 508.200328] ieee80211_do_open+0 x900/0x918 [mac80211] [ 508.205372] __dev_open+0xcc/0x150 [ 508.208763] __dev_change_flags+0x134/0x198 [ 508.212937] dev_change_flags+0x20/0x60 [ 508.216764] devinet_ioctl+0x3e8/0x748 [ 508.220503] inet_ioctl+0x1e4/0x350 [ 508.223983] sock_do_ioctl+0x48/0x2 a0 [ 508.227635] sock_ioctl+0x310/0x4f8 [ 508.231116] do_vfs_ioctl+0xa4/0xac0 [ 508.234681 ] ksys_ioctl+0x44/0x90 [ 508.237985] __arm64_sys_ioctl+0x1c/0x48 [ 508.241901] el0_svc_common.constprop.1+0x7c/0x100 [ 508.246681] el0_svc_handler+0x18/0 x20 [ 508.250421] el0_svc+0x8/0x1c8 [ 508.253465] ---[ fin rastrear c7b90fee13d72c39 ]--- [ 508.261278]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: mt7615: corrige la pérdida de memoria en mt7615_coredump_work. Similar al problema solucionado en mt7921_coredump_work, soluciona una posible pérdida de memoria en la rutina mt7615_coredump_work.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921: arreglar pérdida de memoria en mt7921_coredump_work. Corrige la posible pérdida de memoria en mt7921_coredump_work.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7915: fix tx skb dma unmap. El primer puntero en el txp también debe desasignarse; de lo contrario, se filtrarán entradas de mapeo DMA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7615: fix tx skb dma unmap. El primer puntero en el txp también debe desasignarse; de lo contrario, se filtrarán entradas de mapeo DMA

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Fix pte update for kernel memory on radix<br /> <br /> When adding a PTE a ptesync is needed to order the update of the PTE<br /> with subsequent accesses otherwise a spurious fault may be raised.<br /> <br /> radix__set_pte_at() does not do this for performance gains. For<br /> non-kernel memory this is not an issue as any faults of this kind are<br /> corrected by the page fault handler. For kernel memory these faults<br /> are not handled. The current solution is that there is a ptesync in<br /> flush_cache_vmap() which should be called when mapping from the<br /> vmalloc region.<br /> <br /> However, map_kernel_page() does not call flush_cache_vmap(). This is<br /> troublesome in particular for code patching with Strict RWX on radix.<br /> In do_patch_instruction() the page frame that contains the instruction<br /> to be patched is mapped and then immediately patched. With no ordering<br /> or synchronization between setting up the PTE and writing to the page<br /> it is possible for faults.<br /> <br /> As the code patching is done using __put_user_asm_goto() the resulting<br /> fault is obscured - but using a normal store instead it can be seen:<br /> <br /> BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c<br /> Faulting instruction address: 0xc00000000008bd74<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV<br /> Modules linked in: nop_module(PO+) [last unloaded: nop_module]<br /> CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43<br /> NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810<br /> REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty)<br /> MSR: 9000000000009033 CR: 44002884 XER: 00000000<br /> CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1<br /> <br /> This results in the kind of issue reported here:<br /> https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/<br /> <br /> Chris Riedl suggested a reliable way to reproduce the issue:<br /> $ mount -t debugfs none /sys/kernel/debug<br /> $ (while true; do echo function &gt; /sys/kernel/debug/tracing/current_tracer ; echo nop &gt; /sys/kernel/debug/tracing/current_tracer ; done) &amp;<br /> <br /> Turning ftrace on and off does a large amount of code patching which<br /> in usually less then 5min will crash giving a trace like:<br /> <br /> ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000)<br /> ------------[ ftrace bug ]------------<br /> ftrace failed to modify<br /> [] napi_busy_loop+0xc/0x390<br /> actual: 11:3b:47:4b<br /> Setting ftrace call site to call ftrace function<br /> ftrace record flags: 80000001<br /> (1)<br /> expected tramp: c00000000006c96c<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8<br /> Modules linked in: nop_module(PO-) [last unloaded: nop_module]<br /> CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1<br /> NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0<br /> REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a)<br /> MSR: 900000000282b033 CR: 28008848 XER: 20040000<br /> CFAR: c0000000001a9c98 IRQMASK: 0<br /> GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022<br /> GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8<br /> GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118<br /> GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000<br /> GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008<br /> GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8<br /> GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020<br /> GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0<br /> NIP ftrace_bug+0x28c/0x2e8<br /> LR ftrace_bug+0x288/0x2e8<br /> Call T<br /> ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: elimina los permisos WO en las entradas de paginación de segundo nivel. Cuando la tabla de páginas de primer nivel se utiliza para la traducción IOVA, solo admite permisos de solo lectura y lectura-escritura. . El permiso de sólo escritura no se admite ya que el bit PRESENTE (que implica permiso de lectura) siempre debe establecerse. Cuando usamos el segundo nivel, todavía otorgamos permisos separados que permiten WriteOnly, lo que parece inconsistente e incómodo. Queremos tener un comportamiento consistente. Después de pasar al primer nivel, no queremos que las cosas funcionen a veces y se rompan si usamos el segundo nivel para las mismas asignaciones. Por lo tanto, elimine esta configuración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: omitir la agregación L4 para paquetes de túnel UDP Si NETIF_F_GRO_FRAGLIST o NETIF_F_GRO_UDP_FWD están habilitados y hay túneles UDP disponibles en el sistema, udp_gro_receive() podría terminar realizando la agregación L4 (ya sea SKB_GSO_UDP_L4 o SKB_GSO_FRAGLIST) en el nivel del túnel UDP externo para paquetes que transportan efectivamente un encabezado de túnel UDP. Eso podría causar corrupción del protocolo interno. Si, por ejemplo, los paquetes relevantes llevan un encabezado vxlan, se ignorarán/agregarán diferentes ID de vxlan al mismo paquete GSO. Los encabezados internos también se ignorarán, de modo que, por ejemplo, los paquetes push TCP sobre vxlan se mantendrán en el motor GRO hasta el próximo lavado, etc. Simplemente omita la ruta de código SKB_GSO_UDP_L4 y SKB_GSO_FRAGLIST si el paquete actual podría aterrizar en un túnel UDP, y deje que udp_gro_receive() haga GRO a través de udp_sk(sk)-&amp;gt;gro_receive. La verificación implementada en este parche es más amplia de lo estrictamente necesario, ya que el túnel UDP existente podría configurarse, por ejemplo, encima de un dispositivo diferente: podríamos terminar omitiendo GRO para algunos paquetes. De todos modos, se trata de una carcasa de esquina muy delgada y cubrirla agregará bastante complejidad. v1 -&amp;gt; v2: - con suerte aclarar el mensaje de confirmación