Vulnerabilidades

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 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: elimina vsock de la tabla conectada cuando la conexión es interrumpida por una señal vsock_connect() espera que el socket ya esté en el estado TCP_ESTABLISHED cuando la tarea de conexión se activa con una señal pendiente. Si esto sucede, el socket estará en la tabla conectada y no se eliminará cuando se restablezca el estado del socket. En esta situación, es común que el proceso vuelva a intentar conectar() y, si la conexión es exitosa, el socket se agregará a la tabla conectada por segunda vez, corrompiendo la lista. Evite esto llamando a vsock_remove_connected() si se recibe una señal mientras se espera una conexión. Esto es inofensivo si el socket no está en la tabla conectada, y si está en la tabla, eliminarlo evitará la corrupción de la lista debido a una doble adición. Nota para la compatibilidad: este parche requiere d5afa82c977e ("vsock: eliminación correcta del socket de la lista"), que se encuentra en todos los árboles estables actuales excepto 4.9.y.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iwlwifi: corrige el use-after-free Si no había ningún firmware presente (o, presumiblemente, no se pudieron analizar todos los archivos de firmware), terminamos desvinculándolo llamando a device_release_driver( ), que llama a remove(), que luego en iwlwifi llama a iwl_drv_stop(), liberando la estructura 'drv'. Sin embargo, el nuevo código que agregué seguirá accediendo erróneamente a él después de que se haya liberado. Establezca 'failure=false' en este caso para evitar el acceso; todos los datos ya se liberaron de todos modos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-rdma: soluciona el posible use-after-free en el transporte error_recovery work Mientras nvme_rdma_submit_async_event_work verifica el control y el estado de la cola antes de preparar el comando AER y programar io_work, para evitar completamente una ejecución donde esta verificación no es confiable, el trabajo de recuperación de errores debe eliminar async_event_work antes de continuar destruyendo la cola de administración después de configurar el estado de control en RESETTING de manera que no haya ejecución .submit_async_event y el propio controlador de recuperación de errores cambie el estado de control.