Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrige la desreferenciación del puntero NULL en smc_vlan_by_tcpsk() Coverity informa un posible problema de desreferenciación de NULL: en smc_vlan_by_tcpsk(): 6. return_null: netdev_lower_get_next devuelve NULL (comprobado 29 de 30 veces). 7. var_assigned: Asignación: ndev = valor de retorno NULL de netdev_lower_get_next. 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower); CID 1468509 (#1 de 1): Desreferenciar valor de retorno nulo (NULL_RETURNS) 8. desreferencia: Desreferenciar un puntero que podría ser NULL ndev al llamar a is_vlan_dev. 1624 if (is_vlan_dev(ndev)) { Elimine la implementación manual y use netdev_walk_all_lower_dev() para iterar sobre los dispositivos inferiores. Mientras esté en él, elimine un comentario de parámetro de función obsoleto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro: protege el controlador de firmware defectuoso Al procesar eventos de activación/desactivación de puerto generados por el firmware del dispositivo, el controlador se protege de eventos informados para puertos locales inexistentes, pero no el puerto de la CPU (puerto local 0), que existe, pero carece de netdev. Esto puede resultar en una desreferencia del puntero NULL al llamar a netif_carrier_{on,off}(). Solucione este problema cancelando el proceso con antelación al procesar un evento informado para el puerto de la CPU. El problema solo se observó cuando se ejecutaba sobre un emulador con errores.

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)