Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/proc: task_mmu.c: no lea el recuento de mapas para la entrada de migración. El syzbot informó el siguiente ERROR: ERROR del kernel en include/linux/page-flags.h:785. código de operación no válido: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01 /2011 RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [en línea] RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744 Seguimiento de llamadas: page_mapcount include/linux/mm.h:837 [en línea] smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466 smaps_pte_entry fs/proc/task_mmu.c:538 [en línea] smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601 walk_pmd_range mm/pagewalk.c :128 [en línea] walk_pud_range mm/pagewalk.c:205 [en línea] walk_p4d_range mm/pagewalk.c:240 [en línea] walk_pgd_range mm/pagewalk.c:277 [en línea] __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379 walk_page_vma+0x277/0x350 mm/pagewalk.c:530 smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768 smap_gather_stats fs/proc/task_mmu.c:741 [en línea] show_smap+0xc6/0x440 fs/ proc/task_mmu.c:822 seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272 seq_read+0x3e0/0x5b0 fs/seq_file.c:162 vfs_read+0x1b5/0x600 fs/read_write.c:479 ksys_read+0x12d/0x250 f s/ read_write.c:619 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae El reproductor estaba intentando leer /proc/ $PID/smaps al llamar a MADV_FREE mientras tanto. MADV_FREE puede dividir THP si se solicita para THP parcial. Puede desencadenar la siguiente ejecución: CPU A CPU B ----- ----- smaps walk: MADV_FREE: page_mapcount() PageCompound() split_huge_page() página = composite_head(page) PageDoubleMap(page) Al llamar a PageDoubleMap() Esta página ya no es una página final de THP, por lo que se activa el ERROR. Esto podría solucionarse mediante un recuento elevado de la página antes de llamar a mapcount, pero eso evitaría que cuente las entradas de migración, y parece excesivo porque la ejecución podría ocurrir cuando PMD se divide, por lo que todas las entradas PTE de las páginas finales son en realidad entradas de migración. y smaps_account() trata las entradas de migración como mapcount == 1 como señaló Kirill. Agregue un nuevo parámetro para smaps_account() para indicar que esta entrada es una entrada de migración y luego omita llamar a page_mapcount(). No deje de obtener mapcount para entradas privadas de dispositivos, ya que rastrean referencias con mapcount. Pagemap también tiene un problema similar, aunque no se informó. Lo arreglé también. [shy828301@gmail.com: v4] Enlace: https://lkml.kernel.org/r/20220203182641.824731-1-shy828301@gmail.com [nathan@kernel.org: evitar advertencia de variable no utilizada en pagemap_pmd_range()] Enlace: https://lkml.kernel.org/r/20220207171049.1102239-1-nathan@kernel.org

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: ti: corrige el centinela faltante para clk_div_table _get_table_maxdiv() intenta acceder a la matriz "clk_div_table" fuera del límite definido en phy-j721e-wiz.c. Agregue una entrada centinela para evitar el siguiente error global fuera de los límites informado al habilitar KASAN. [9.552392] ERROR: KASAN: global fuera de los límites en _get_maxdiv+0xc0/0x148 [9.558948] Lectura de tamaño 4 en la dirección ffff8000095b25a4 por tarea kworker/u4:1/38 [9.565926] [9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 No contaminado 5.16.0-116492-gdaadb3bd0e8d-dirty #360 [ 9.576242] Nombre de hardware: Texas Instruments J721e EVM (DT) [ 9.581832] Cola de trabajo: events_unbound deferred_probe_work_func [ 9.587708] Seguimiento de llamadas: [ 9.590174] dump_backtrace+0x20c/0x218 [ 9.594038] show_stack+0x18/0x68 [ 9.597375] dump_stack_lvl+0x9c/0xd8 [ 9.601062] print_address_description.constprop.0+0x78/0x334 [ 9.606830] 0x1f0/0x260 [9.610517] __asan_load4+0x9c/0xd8 [ 9.614030] _get_maxdiv+0xc0/0x148 [ 9.617540] divider_determinate_rate+0x88/0x488 [ 9.622005] divider_round_rate_parent+0xc8/0x124 [ 9.626729] wiz_clk_div_round_rate+0x54/0x68 [ 9.6 31113] clk_core_determine_round_nolock+0x124/0x158 [ 9.636448] clk_core_round_rate_nolock+0x68/0x138 [ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8 [ 9.645987] clk_set_rate+0x50/0xa8 [ 9.649499] cdns_sierra_phy_init+0x88/0x248 [ 9.653794] phy_init+0x98/0x108 [ 9.657046] cdns_pcie_enable_phy+0xa0/0x170 [ 9.661340] cdns_pcie_init_phy+0x250/0x2b0 [ 9.665546] j721e_pcie_probe+ 0x4b8/0x798 [ 9.669579] platform_probe+0x8c/0x108 [ 9.673350] very_probe+0x114/0x630 [ 9.677037] __driver_probe_device+0x18c/0x220 [ 9.681505] driver_probe_device+0xac/0x 150 [9.685712] __device_attach_driver+0xec/0x170 [9.690178] bus_for_each_drv+0xf0/ 0x158 [ 9.694124] __device_attach+0x184/0x210 [ 9.698070] device_initial_probe+0x14/0x20 [ 9.702277] bus_probe_device+0xec/0x100 [ 9.706223] deferred_probe_work_func+0x124/0x1 80 [ 9.710951] proceso_un_trabajo+0x4b0/0xbc0 [ 9.714983] hilo_trabajador+0x74/0x5d0 [ 9.718668] kthread+0x214/0x230 [ 9.721919] ret_from_fork+0x10/0x20 [ 9.725520] [ 9.727032] La dirección del error pertenece a la variable: [ 9.732183] clk_div_table+0x24/0x440

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vt_ioctl: corrige array_index_nospec en vt_setactivate array_index_nospec garantiza que un valor fuera de los límites se establezca en cero en la ruta transitoria. Disminuir el valor en uno posteriormente provoca un desbordamiento de enteros transitorio. vsa.console debe reducirse primero y luego desinfectarse con array_index_nospec. Agradecimientos de Kasper: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida del grupo VUSec en VU Amsterdam.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: ax88179_178a: Reparar accesos fuera de los límites en RX fixup ax88179_rx_fixup() contiene varios accesos fuera de los límites que pueden ser activados por un archivo malicioso (o defectuoso). Dispositivo USB, en particular: - La matriz de metadatos (hdr_off..hdr_off+2*pkt_cnt) puede estar fuera de los límites, provocando lecturas OOB y (en sistemas big-endian) cambios de endianidad OOB. - Un paquete puede superponerse a la matriz de metadatos, lo que provoca un cambio de endianidad OOB posterior que corrompe los datos utilizados por un SKB clonado que ya se ha transferido a la pila de red. - Se puede construir un paquete SKB cuya cola esté mucho más allá de su extremo, lo que hace que los datos del montón fuera de los límites se consideren parte de los datos del SKB. He probado que esto puede ser utilizado por un dispositivo USB malicioso para enviar una solicitud de eco ICMPv6 falsa y recibir una respuesta de eco ICMPv6 en respuesta que contiene datos aleatorios del montón del kernel. Probablemente también sea posible obtener escrituras OOB a partir de esto en un sistema little-endian de alguna manera, tal vez activando skb_cow() a través del procesamiento de opciones de IP, pero no lo he probado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: eeprom: ee1004: limitar las lecturas de i2c a I2C_SMBUS_BLOCK_MAX El commit effa453168a7 ("i2c: i801: No corrija silenciosamente el tamaño de transferencia no válido") reveló que ee1004_eeprom_read() no limitaba adecuadamente cuántas bytes para leer a la vez. En particular, i2c_smbus_read_i2c_block_data_or_emulated() toma la longitud para leer como u8. Si el recuento == 256 después de tener en cuenta el desplazamiento y el límite de la página, la conversión a u8 se desborda. Y esto es común cuando el espacio del usuario intenta leer toda la EEPROM a la vez. Para solucionarlo, limite cada lectura a I2C_SMBUS_BLOCK_MAX (32) bytes, ya que la longitud máxima que permite i2c_smbus_read_i2c_block_data_or_emulated().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mtd: rawnand: gpmi: no filtrar la referencia de PM en la ruta de error Si gpmi_nfc_apply_timings() falla, se debe descartar el contador de uso del tiempo de ejecución de PM.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: mscc: ocelot: fix use-after-free en ocelot_vlan_del() ocelot_vlan_member_del() liberará la estructura ocelot_bridge_vlan, por lo que si es la misma que la pvid_vlan del puerto al que accedemos después, a lo que accedemos es a la memoria liberada. Corrija el error determinando si se debe borrar ocelot_port->pvid_vlan antes de llamar a ocelot_vlan_member_del().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: evite sobrescribir las copias de las funciones de devolución de llamada de clcsock. Las funciones de devolución de llamada de clcsock se guardarán y reemplazarán durante la reserva. Pero si el retroceso ocurre más de una vez, las copias de estas funciones de devolución de llamada se sobrescribirán incorrectamente, lo que provocará un problema de llamada en bucle: clcsk->sk_error_report |- smc_fback_error_report() <------------ ------------------| |- smc_fback_forward_wakeup() | (bucle) |- clcsock_callback() (sobrescrito incorrectamente) | |- smc->clcsk_error_report() ------------------| Por lo tanto, este parche soluciona el problema al guardar estos punteros de función solo una vez en el respaldo y evitar la sobrescritura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: af_alg - deshacerse de alg_memory_allocated alg_memory_allocated no parece usarse realmente. alg_proto tiene un campo .memory_allocated, pero ningún .sysctl_mem correspondiente. Esto significa que sk_has_account() devuelve verdadero, pero todos los usuarios de sk_prot_mem_limits() activarán una desreferencia NULL [1]. Esto no fue un problema hasta la adición de SO_RESERVE_MEM. falla de protección general, probablemente para dirección no canónica 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en rango [0x0000000000000008-0x0000000000000000f] CPU: 1 PID: 3591 Comm: No contaminado 5.17.0 -rc3-syzkaller-00316-gb81b1829e7e3 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:sk_prot_mem_limits include/net/sock.h:1523 [en línea] RIP: 0010: sock_reserve_memory+0x1d7/0x330 net/core/sock.c:1000 Código: 08 00 74 08 48 89 ef e8 27 20 bb f9 4c 03 7c 24 10 48 8b 6d 00 48 83 c5 08 48 89 e8 48 c1 e8 48b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 ef e8 fb 1f bb f9 48 8b 6d 00 4c 89 ff 48 RSP: 0018:ffffc90001f1fb68 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff88814aabc000 RCX: dffffc0000000000 RDX : 0000000000000001 RSI: 0000000000000008 RDI: ffffffff90e18120 RBP: 0000000000000008 R08: dffffc0000000000 R09: ffffbfff21c3025 R10: ffffbfff21c3 025 R11: 0000000000000000 R12: ffffffff8d109840 R13: 0000000000001002 R14: 0000000000000001 R15: 0000000000000001 FS: 0000555556e08300 (0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007FC74416F130 DR6: 0000000000FFFE0FF0 DR7: 0000000000000400 TRACE DE LLAMADA: Sock_SetSockOpt+0x14a9/0x3a30 net/core/sock.c:1446 __sys_setsockopt+0x5af/0x980 net/socket.c:2176 __do_sys_setsockopt net/socket.c:2191 [en línea] __se_sys_setsockopt net/socket.c:2188 [en línea] 0xc0 neto/ socket.c:2188 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fc7440fddc9 Código: 00 00 00 75 05 48 83 c4 28 c3 e8 51 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe98f07968 EFLAGS: 00000246 ORIG_RAX: 00000000000000036 RAX: ffffffffffffffda RBX: 003 RCX: 00007fc7440fddc9 RDX: 0000000000000049 RSI: 0000000000000001 RDI: 0000000000000004 RBP: 0000000000000000 R08: 00000000000000004 R09 : 00007ffe98f07990 R10: 0000000020000000 R11: 0000000000000246 R12: 00007ffe98f0798c R13: 00007ffe98f079a0 R14: 00007ffe98f079e0 R15: 0000000000000 Módulos vinculados en: ---[ end trace 0000000000000000 ]--- RIP: 0010:sk_prot_mem_limits include/net/sock. h:1523 [en línea] RIP: 0010:sock_reserve_memory+0x1d7/0x330 net/core/sock.c:1000 Código: 08 00 74 08 48 89 ef e8 27 20 bb f9 4c 03 7c 24 10 48 8b 6d 00 48 83 c5 08 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 ef e8 fb 1f bb f9 48 8b 6d 00 4c 89 ff 48 RSP 0018:ffffc900 01f1fb68EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff88814aabc000 RCX: dffffc0000000000 RDX: 0000000000000001 RSI: 00000000000000008 RDI: ffffffff90e18120 RBP: 000000008 R08: dffffc0000000000 R09: ffffbfff21c3025 R10: ffffbfff21c3025 R11: 00000000000000000 R12: ffffffff8d109840 R13: 0000000000000001002 0000000000000001 R15: 0000000000000001 FS: 0000555556e08300(0000 ) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc74416f130 CR3: 0000000073d9e 000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp: corregir el use after free El análisis estático de Clang informa este problema route.c:425:4: advertencia: uso de la memoria después de liberarla trace_mctp_key_acquire(key); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Cuando mctp_key_add() falla, la clave se libera pero luego se usa en trace_mctp_key_acquire(). Agregue una declaración else para usar la clave solo cuando mctp_key_add() sea exitoso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: lantiq_gswip: corregir el use after free en gswip_remove() of_node_put(priv->ds->slave_mii_bus->dev.of_node) debe realizarse antes de mdiobus_free(priv-> ds->slave_mii_bus).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cfg80211: corrige la ejecución en la destrucción de la interfaz del propietario de netlink. Mi solución anterior aquí para arreglar el punto muerto dejó una ejecución donde exactamente el mismo punto muerto (consulte la confirmación original a la que se hace referencia a continuación) aún puede ocurrir si cfg80211_destroy_ifaces () ya se ejecuta mientras nl80211_netlink_notify() todavía marca algunas interfaces como nl_owner_dead. La ejecución ocurre porque tenemos dos bucles aquí: primero dev_close() todos los netdevs y luego los destruimos. Si también tenemos dos netdevs (aunque el primero solo necesita ser un wdev), entonces podemos encontrar uno durante la primera iteración, cerrarlo e ir a la segunda iteración, pero luego encontrar dos e intentar destruir también el que tenemos. Aún no ha cerrado. Solucione este problema iterando solo una vez.