Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: evitar interbloqueo entre hci_dev-&amp;gt;lock y socket lock. el commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") agregó una dependencia entre socket lock y hci_dev-&amp;gt;lock que podría provocar a un punto muerto. Resulta que hci_conn_get_phy() no depende de ninguna manera de que hdev sea inmutable durante el tiempo de ejecución de esta función, ni siquiera mira a ninguno de los miembros de hdev y, como tal, no es necesario mantener ese bloqueo. Esto soluciona el problema de bloqueo a continuación: ============================================ =========== ADVERTENCIA: posible dependencia de bloqueo circular detectada 5.12.0-rc1-00026-g73d464503354 #10 No contaminado ------------------- ----------------------------------- bluetoothd/1118 está intentando adquirir el bloqueo: ffff8f078383c078 (&amp;amp;hdev-&amp;gt;lock ){+.+.}-{3:3}, en: hci_conn_get_phy+0x1c/0x150 [bluetooth] pero la tarea ya está bloqueada: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0 }, en: l2cap_sock_getsockopt+0x8b/0x610 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -&amp;gt; #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+ 0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] Process_one_work+0x244/0x5f0 trabajador_thread+0x3c/0x380 kthread+0 x13e/0x160 ret_from_fork+0x22/0x30 -&amp;gt; #2 (&amp;amp;chan-&amp;gt;lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+ 0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae -&amp;gt; #1 (&amp;amp;conn-&amp;gt;chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0 x322/ 0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae -&amp;gt; #0 (&amp;amp;hdev- &amp;gt;bloquear){+.+.}-{ 3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc /0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/ 0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae otra información que podría ayudarnos a depurar esto: Existe cadena de: &amp;amp;hdev-&amp;gt;lock --&amp;gt; &amp;amp;chan-&amp;gt;lock#2/1 --&amp;gt; sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Posible escenario de bloqueo inseguro: CPU0 CPU1 - --- ---- bloqueo(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); bloquear(&amp;amp;chan-&amp;gt;bloquear#2/1); bloquear(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); bloquear(&amp;amp;hdev-&amp;gt;bloquear); *** DEADLOCK *** 1 bloqueo retenido por bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, en: l2cap_sock_getsockopt+0x8b/0x610 pila [bluetooth] backtrace: CPU: 3 PID: 1118 Comm: bluetoothd No contaminado 5.12.0-rc1-00026-g73d464503354 #10 Nombre de hardware: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16) 31/05/2017 Seguimiento de llamadas: dump_stack+0x7 f/0xa1 check_noncircular+0x105/0x120? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50? lock_is_held_type+0xb4/0x120? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0? mark_held_locks+0x49/0x70? mark_held_locks+0x49/0x70? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x ---truncado---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ataflop: potencial fuera de los límites en do_format() La función utiliza "tipo" como índice de matriz: q = unidad[unidad].disco[tipo]-&amp;gt;cola; Desafortunadamente, la verificación de los límites en "tipo" no se realiza hasta más adelante en la función. Solucione este problema moviendo la verificación de los límites al inicio.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring: soluciona comprobaciones de desbordamiento en los buffers de suministro que Colin informó antes de posibles problemas de desbordamiento y extensión de firma en io_provide_buffers_prep(). Como Linus señaló que el intento anterior no hizo nada útil, consulte d81269fecb8ce ("io_uring: corrige la extensión de signo provide_buffers"). Haga esto con la ayuda de los ayudantes check__overflow. Y corrija el tipo struct io_provide_buf::len, ya que no tiene mucho sentido mantenerlo firmado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: q6afe-clocks: corrección de reprobación del controlador El controlador Q6afe-clocks puede ser reprobado. Por ejemplo, si los servicios APR se reinician después de la falla del firmware. Sin embargo, actualmente el controlador Q6afe-clocks fallará porque hw.init se borrará durante la primera llamada a _probe. Vuelva a escribir el controlador para completar los datos del reloj en tiempo de ejecución en lugar de utilizar una gran variedad de relojes estáticos.