Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: virtio: deshabilita el manejo del tiempo de espera Si se alcanza un tiempo de espera, puede resultar en datos incorrectos en el bus I2C y/o daños en la memoria del invitado, ya que el dispositivo aún puede estar funcionando. en los buffers que se le dieron mientras el huésped los liberó. Aquí está, por ejemplo, el inicio de un splat slub_debug que se activó en la siguiente transferencia después de que se obligó a que una transferencia expirara estableciendo un punto de interrupción en el backend (rust-vmm/vhost-device): ERROR kmalloc-1k (No contaminado ): Veneno sobrescrito Primer byte 0x1 en lugar de 0x6b Asignado en virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d 0x115/0x134 i2cdev_ioctl_rdwr+0x16a/ 0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Liberado en virtio_i2c_xfer+0x32e/0x35c edad=244 cpu=0 pid=29 kfree+0x1bd/0x1cc x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115 /0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 No existe una solución sencilla para esto (el controlador siempre tendría que crear búferes de rebote y conservarlos hasta que el dispositivo finalmente devuelva el búferes), así que simplemente deshabilite el soporte de tiempo de espera por ahora.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: corregir el tamaño de vsi->txq_map El enfoque de tener una cola XDP por CPU independientemente de la configuración del usuario expuso un error oculto que podría ocurrir en caso de que el recuento de la cola de Rx difiera del recuento de la cola de Tx . Actualmente, el tamaño de vsi->txq_map es igual al doble de vsi->alloc_txq, lo cual no es correcto debido al hecho de que los anillos XDP se basaban anteriormente en el recuento de colas de Rx. A continuación se puede ver el símbolo cuando se usa ethtool -L y se configuran los anillos XDP: [682.875339] ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000000f [682.883403] #PF: acceso de lectura del supervisor en modo kernel [682.889345] #PF: error_code( 0x0000) - página no presente [682.895289] PGD 0 P4D 0 [682.898218] Ups: 0000 [#1] PREEMPT SMP PTI [682.903055] CPU: 42 PID: 2878 Comm: ethtool Contaminado: G OE 5.15.0-rc5+ #1 [ 682.912214] Nombre del hardware: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 19/05/2016 [ 682.923380] RIP: 0010:devres_remove+0x44/0x130 [ 682.928527] 49 89 f4 55 48 89 fd 4c 89 ff 53 48 83 ec 10 e8 92 b9 49 00 48 8b 9d a8 02 00 00 48 8d 8d a0 02 00 00 49 89 c2 48 39 cb 74 0f <4c> 3b 63 10 74 25 8 8b 5b 08 48 39 cb 75 f1 4c 89 ff 4c 89 d6 e8 [ 682.950237] RSP: 0018:ffffc90006a679f0 EFLAGS: 00010002 [ 682.956285] RAX: 0000000000000286 RBX: RCX: ffff88908343a370 [ 682.964538] RDX: 0000000000000001 RSI: ffffffff81690d60 RDI: 0000000000000000 [ 682.972789] RBP : ffff88908343a0d0 R08: 0000000000000000 R09: 0000000000000000 [ 682.981040] R10: 00000000000000286 R11: 3ffffffffffffffff R12: ffffffff81690d60 [ 682.989282] R13: ffffffff81690a00 R14: ffff8890819807a8 R15: ffff88908343a36c [ 682.997535] FS: 00007f08c7bfa740(0000) GS:ffff88a03fd00000(0 000) knlGS:0000000000000000 [ 683.006910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 683.013557] CR2: 0000000000000000f CR3: 0000001080a66003 CR4: 06e0 [ 683.021819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 683.030075] DR3: 0000000000000000 DR6: 0ff0DR7: 0000000000000400 [683.038336] Seguimiento de llamadas: [683.041167] devm_kfree+0x33/0x50 [683.045004] ice_vsi_free_arrays+0x5e/0xc0 [ice] [683.050380] 8/0x750 [hielo] [683.055543] ice_vsi_recfg_qs+0x9a/0x110 [hielo] [683.060697 ] ice_set_channels+0x14f/0x290 [ice] [ 683.065962] ethnl_set_channels+0x333/0x3f0 [ 683.070807] genl_family_rcv_msg_doit+0xea/0x150 [ 683.076152] 1d0 [683.080289] ? canales_prepare_data+0x60/0x60 [683.085432]? genl_get_cmd+0xd0/0xd0 [ 683.089667] netlink_rcv_skb+0x50/0xf0 [ 683.094006] genl_rcv+0x24/0x40 [ 683.097638] netlink_unicast+0x239/0x340 [ 683.102177] endmsg+0x22e/0x470 [ 683.106717] sock_sendmsg+0x5e/0x60 [ 683.110756] __sys_sendto+ 0xee/0x150 [683.114894] ? handle_mm_fault+0xd0/0x2a0 [683.119535]? do_user_addr_fault+0x1f3/0x690 [ 683.134173] __x64_sys_sendto+0x25/0x30 [ 683.148231] do_syscall_64+0x3b/0xc0 [ 683.161992] Entry_SYSCALL_64_after_hwframe+0x44/ 0xae Solucione este problema teniendo en cuenta el valor que arroja num_possible_cpus() produce además de vsi->alloc_txq en lugar de duplicar este último.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf hist: corrige la pérdida de memoria de un perf_hpp_fmt perf_hpp__column_unregister() elimina una entrada de una lista pero no libera la memoria, lo que provoca una pérdida de memoria detectada por el sanitizante de fugas. Agregue free y al mismo tiempo reduzca el alcance de la función a estático.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: corrige la pérdida de memoria en fib6_rule_suppress El kernel pierde memoria cuando una regla `fib` está presente en las reglas de firewall de nftables de IPv6 y una regla de supresión_prefix está presente en las reglas de enrutamiento de IPv6 (utilizadas por ciertas herramientas como wg-quick). En tales escenarios, cada paquete entrante perderá una asignación en el caché de losa `ip6_dst_cache`. Después de algunas horas de `bpftrace`-ing y lectura del código fuente, rastreé el problema hasta ca7a03c41753 ("ipv6: no libere rt si FIB_LOOKUP_NOREF está configurado en la regla de supresión"). El problema con ese cambio es que los `args->flags` genéricos siempre tienen `FIB_LOOKUP_NOREF` configurado[1][2] pero el indicador específico de IPv6 `RT6_LOOKUP_F_DST_NOREF` podría no estarlo, lo que lleva a que `fib6_rule_suppress` no disminuya el recuento cuando necesario. Cómo reproducir: - Agregue la siguiente regla nftables a una cadena de enrutamiento previo: meta nfproto ipv6 fib saddr. marca . iif oif falta gota Esto se puede hacer con: sudo nft create table inet test sudo nft create chain inet test test_chain '{ tipo filtro gancho prerouting filtro de prioridad + 10; aceptar política; }' sudo nft agregar regla inet test test_chain meta nfproto ipv6 fib saddr. marca . iif oif falta gota - Ejecutar: sudo ip -6 regla agregar tabla principal suprimir_prefixlength 0 - Ver `sudo slabtop -o | grep ip6_dst_cache` para ver el aumento del uso de memoria con cada paquete ipv6 entrante. Este parche expone los indicadores específicos del protocolo a la función `suprimir` específica del protocolo y verifica el argumento `flags` específico del protocolo para RT6_LOOKUP_F_DST_NOREF en lugar del FIB_LOOKUP_NOREF genérico al disminuir el recuento, de esta manera. [1]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L71 [2]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038 c3266e26/net /ipv6/fib6_rules.c#L99

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tulip: de4x5: soluciona el problema de que la matriz 'lp->phy[8]' puede estar fuera de límites En la línea 5001, si todos los ID de la matriz 'lp ->phy[8]' no es 0, cuando termina 'for', 'k' es 8. En este momento, la matriz 'lp->phy[8]' puede estar fuera de límite.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ethernet: hisilicon: hns: hns_dsaf_misc: corrige un posible desbordamiento de matriz en hns_dsaf_ge_srst_by_port() La sentencia if: if (port >= DSAF_GE_NUM) return; limita el valor del puerto a menos de DSAF_GE_NUM (es decir, 8). Sin embargo, si el valor del puerto es 6 o 7, podría producirse un desbordamiento de la matriz: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; porque la longitud de dsaf_dev->mac_cb es DSAF_MAX_PORT_NUM (es decir, 6). Para solucionar este posible desbordamiento de la matriz, primero verificamos el puerto y si es mayor o igual a DSAF_MAX_PORT_NUM, la función regresa.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: sata_fsl: corrige UAF en sata_fsl_port_stop cuando rmmod sata_fsl Cuando se ejecuta el comando `rmmod sata_fsl.ko` en el PPC64 GNU/Linux se reporta un error: ====== ==================================================== ========== ERROR: No se puede manejar el acceso a los datos del kernel al leer en 0x80000800805b502c Ups: Acceso al kernel del área defectuosa, firma: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034 ] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Seguimiento de llamadas: .free_irq+0x1c/0x4e0 (no confiable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0. driver_detach+0x64/0xd0 . bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] .__se_sys_delete_module+0x1ec/0x2d0 .system_call_exception+ 0xfc/0x1f0 system_call_common+0xf8/0x200 ======= ==================================================== ========= La activación del ERROR se muestra en la siguiente pila: driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap( host_priv->hcr_base); <---- desasignar kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <--- - UAF host->ops->host_stop(host) Las funciones iounmap(host_priv->hcr_base) y kfree(host_priv) no deben ejecutarse en drv->remove. Estas funciones deben ejecutarse en host_stop después de port_stop. Por lo tanto, movemos estas funciones a la nueva función sata_fsl_host_stop y vinculamos la nueva función a host_stop.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/amdgpu: corrige una posible fuga de mem en la función amdgpu_get_xgmi_hive, cuando falla kobject_init_and_add Hay una posible fuga de mem si no se llama a kobject_put.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/amdkfd: corrige el pánico del kernel cuando el reinicio falla y se activa nuevamente. En la configuración SRIOV, el reinicio puede no lograr que asic vuelva a la normalidad, pero ya se ha llamado a detener cpsch, el No se llamará a start_cpsch ya que en este caso no hay ningún currículum. Cuando el reinicio se activa nuevamente, el controlador debe evitar realizar la desinicialización nuevamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7915: corrige la desreferencia del puntero NULL en mt7915_get_phy_mode. Corrija la siguiente desreferencia del puntero NULL en la rutina mt7915_get_phy_mode agregando una interfaz ibss al controlador mt7915. [ 101.137097] wlan0: activa una nueva exploración para encontrar un IBSS al que unirse [ 102.827039] wlan0: crea una nueva red IBSS, BSSID 26:a4:50:1a:6e:69 [ 103.064756] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 [ 103.073670] Información de cancelación de memoria: [ 103.076520] ESR = 0x96000005 [ 103.079614] EC = 0x25: DABT (EL actual), IL = 32 bits [ 103.084934] SET = 0, FnV = 0 [ 103.088042] EA = 0, 1PTW = 0 [ 103.091215] Información de cancelación de datos: [ 103.094104] ISV = 0, ISS = 0x00000005 [ 103.098041] CM = 0, WnR = 0 [ 103.101044] tabla de páginas de usuario: páginas de 4k, VA de 39 bits, pgdp=00000000460 b1000 [ 103.107565 ] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [103.116590] Error interno: Ups: 96000005 [#1] SMP [103.189066] CPU: 1 PID: 333 Comunicaciones: kworker/u4:3 No contaminado 5.10.75 #0 [ 103.195498 ] Nombre del hardware: Placa MediaTek MT7622 RFB1 (DT) [103.201124] Cola de trabajo: phy0 ieee80211_iface_work [mac80211] [103.206695] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--) [103.212705] pc: t7915_get_phy_mode+0x68/ 0x120 [MT7915E] [103.218103] LR: MT7915_MCU_ADD_BSS_INFO+0X11C/0X760 [MT7915E] [103.223927] SP: FFFFFFFC011CDB9E0 [103.222235] x29: F8006563098 [103.232545] x27: ffffff8005f4da22 x26: ffffff800685ac40 [103.237855] x25: 000000000000000001 x24: 000000000000011f [ 103.243165] x23: ffffff8005f4e260 x22: ffffff8006567918 [ 103.248475] x21: ffffff8005f4df80 x20: ffffff800685ac58 [ 103.253785] x19: 44400 x18: 0000000000000000 [ 103.259094] x17: 0000000000000000 x16: 0000000000000001 [ 103.264403] x15: 000899c3a2d9d2e4 x14: 99bdc3c3a1c8 [103.269713] x13: 0000000000000000 x12: 0000000000000000 [ 103.275024] x11: ffffffc010e30c20 x10: 0000000000000000 [ 103.280333] x9 : 0000000000000050 x8: ffffff8006567d88 [103.285642] x7: ffffff8006563b5c x6: ffffff8006563b44 [103.290952] x5: 00000000000000002 x4: 0000000000000001 [ 103.2 96262] x3: 0000000000000001 x2: 0000000000000001 [ 103.301572] x1: 0000000000000000 x0: 0000000000000011 [103.306882] Rastreo de llamadas: [103.309328] mt7915_get_phy_mode+0x68/0x120 [mt7915e] [ 378] mt7915_bss_info_changed+0x198/0x200 [mt7915e] [ 103.319941] ieee80211_bss_info_change_notify+0x128/0x290 [mac80211] [ 103.326360] __ieee80211_sta_join_ibss+0x308/0x6c4 [mac80211] [ 103.332171] ieee80211_sta_create_ibss+0x8c/0x10c [mac80211] [ 103.337895] 614 [mac80211] [ 103.343185] ieee80211_iface_work+0x388/0x3f0 [mac80211] [ 103.348495] Process_one_work+0x288/0x690 [ 103.352499] work_thread+0x70/0x464 [ 103.356157] kthread+0x144/0x150 [ 103.359380] ret_from_fork+0x10/0x18 [ 103.362952] Código: 394008c3 52800220 00e4 7100007f (39400023)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx4_en: corrige un error de use-after-free en mlx4_en_try_alloc_resources() En mlx4_en_try_alloc_resources(), se llama a mlx4_en_copy_priv() y se liberará tmp->tx_cq en la ruta del error de mlx4_en_copy_priv(). Después de eso, se llama a mlx4_en_alloc_resources() y hay una desreferencia de &tmp->tx_cq[t][i] en mlx4_en_alloc_resources(), lo que podría llevar a un problema de use-after-free si falla mlx4_en_copy_priv(). Corrija este error agregando una verificación de mlx4_en_copy_priv() Este error fue encontrado por un analizador estático. El análisis emplea verificación diferencial para identificar operaciones de seguridad inconsistentes (por ejemplo, comprobaciones o kfrees) entre dos rutas de código y confirma que las operaciones inconsistentes no se recuperan en la función actual o en las personas que llaman, por lo que constituyen errores. Tenga en cuenta que, como error encontrado mediante análisis estático, puede ser un falso positivo o difícil de activar. Varios investigadores han realizado una revisión cruzada del error. Las compilaciones con CONFIG_MLX4_EN=m no muestran nuevas advertencias y nuestro analizador estático ya no advierte sobre este código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: qlogic: qlcnic: corrigió una desreferencia de puntero NULL en qlcnic_83xx_add_rings() En qlcnic_83xx_add_rings(), se llamará a la función indirecta de ahw->hw_ops->alloc_mbx_args para asignar memoria para cmd.req.arg, y hay una desreferencia del mismo en qlcnic_83xx_add_rings(), lo que podría llevar a una desreferencia del puntero NULL en caso de falla de la función indirecta como qlcnic_83xx_alloc_mbx_args(). Corrija este error agregando una verificación de alloc_mbx_args(); este parche imita la lógica del manejo de fallas de mbx_cmd(). Este error fue encontrado por un analizador estático. El análisis emplea verificación diferencial para identificar operaciones de seguridad inconsistentes (por ejemplo, comprobaciones o kfrees) entre dos rutas de código y confirma que las operaciones inconsistentes no se recuperan en la función actual o en las personas que llaman, por lo que constituyen errores. Tenga en cuenta que, como error encontrado mediante análisis estático, puede ser un falso positivo o difícil de activar. Varios investigadores han realizado una revisión cruzada del error. Las compilaciones con CONFIG_QLCNIC=m no muestran nuevas advertencias y nuestro analizador estático ya no advierte sobre este código.