Vulnerabilidades

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.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: mcast: use la versión rcu-safe de ipv6_get_lladdr() Hace algún tiempo 8965779d2c0e ("ipv6,mcast: siempre mantenga presionado idev->lock antes de mca_lock") cambió ipv6_get_lladdr() a __ipv6_get_lladdr(), que es una versión insegura para rcu. Eso estuvo bien, porque se mantuvo idev->lock para estas rutas de código. En 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") se eliminaron estos bloqueos externos, por lo que probablemente necesitemos restaurar la llamada rcu-safe original. De lo contrario, ocasionalmente obtenemos una máquina que falla o se bloquea con lo siguiente en dmesg: [3405.966610][T230589] falla de protección general, probablemente para la dirección no canónica 0xdead00000000008c: 0000 [#1] SMP NOPTI [3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: GO 5.15.19-cloudflare-2022.2.1 #1 [ 3405.998061][T230589] Nombre de hardware: SUPA-COOL-SERV [ 3406.009552][T230589] Cola de trabajo: mld mld_ifc_work [ 3406 .017224 ][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60 [ 3406.025780][T230589] Código: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 <66> 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b [ 3406.055748][T230589] 0018:ffff94e4b3fc3d10 EFLAGS: 00010202 [ 3406.065617][T230589] RAX: muerto00000000005a RBX: ffff94e4b3fc3d30 RCX: 00000000000000040 [ 3406.077477][T230589] RDX: muerto0000000001 22 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008 [ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000000000 [ 34 06.101445][ T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100 [ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 0000000000 0005dc R15: ffff8c3a31431000 [ 3406.125730][T230589] FS: 0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000 [ 3406.1 38992] [T230589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0350ee0 [ 3406.162421][T230589] Seguimiento de llamadas: [ 3406.170235][T230589] [ 3406.177736 ] [T230589] Mld_newpack+0xfe/0x1a0 [3406.186686] [T230589] add_grhead+0x87/0xa0 [3406.195498] [T230589] add_grec+0x485/0x4e0 [3406.204310] newidle_balance+0x126/0x3f0 [ 3406.214024][T230589] mld_ifc_work+0x15d/0x450 [ 3406.223279][T230589] Process_one_work+0x1e6/0x380 [ 3406.232982][T230589] +0x50/0x3a0 [ 3406.242371][T230589] ? hilo_rescate+0x360/0x360 [ 3406.252175][T230589] kthread+0x127/0x150 [ 3406.261197][T230589] ? set_kthread_struct+0x40/0x40 [ 3406.271287][T230589] ret_from_fork+0x22/0x30 [ 3406.280812][T230589] [ 3406.288937][T230589] Módulos vinculados en: ... [última descarga: kheaders] 3406.476714][T230589 ] ---[ final de seguimiento 3525a7655f2f3b9e ]---