Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_ets: no mire las clases más allá de 'nbands' cuando el número de clases DRR disminuye, la lista activa por turnos puede contener elementos que ya han sido liberados en ets_qdisc_change(). Como consecuencia, es posible ver un bloqueo de desreferencia NULL, causado por el intento de llamar a cl->qdisc->ops->peek(cl->qdisc) cuando cl->qdisc es NULL: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000018 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16 .0-rc1+ #475 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 01/04/2014 RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets] Código: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 <48> 8b 47 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287 RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 00000000000 00000 RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000 RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 000000000000000000000 R10 : 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0 R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100 FS: a9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 0000011070c000 CR4: 0000000000350ee0 Seguimiento de llamadas: qdisc_peek_dequeued+0x29/0x70 [sch_ets] tbf_dequeue+0x22/0x260 [sch_tbf] __qdisc_run+0x7f/0x630 net_tx_action+0x290/0x4c0 ee/0x4f8 irq_exit_rcu+0xf4/0x130 sysvec_apic_timer_interrupt+0x52/0xc0 asm_sysvec_apic_timer_interrupt+0x12/0x20 RIP: 0033:0x7f2aa7fc9ad4 Código: b9 ff ff 48 8b 54 24 18 48 83 c4 08 48 89 ee 48 89 df 5b 5d e9 ed fc ff ff 0f 1f 0 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa <53> 48 83 ec 10 48 8b 05 10 64 33 00 48 8b 00 48 85 c0 0f 85 84 00 RSP: 002b:00007ffe5d33fab8 EFLAGS: 00000202 RAX: 0000002 RBX: 0000561f72c31460 RCX: 0000561f72c31720 RDX: 0000000000000002 RSI: 0000561f72c31722 RDI: 0000561f72c31720 RBP: 000000000000002a R08: 00007ffe5d33fa40 R09: 00000000000000014 R10: 0000000000000000 R11: 000000000000246 R12: 0000561f7187e380 R13: 0000000000000000 R14: 0000000000000000 R15: 0000561f72c31460 Módulos vinculados en: sch_ets sch_tbf dummy matar iTCO_wdt intel_rapl_msr iTCO_vendor_support intel_rapl_common joydev virtio_balloon lpc_ich i2c_i801 i2c_smbus pcspkr ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel serio_raw libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm _log dm_mod CR2: 0000000000000018 Asegurarse de que 'alist' nunca se pusiera a cero [1] no fue suficiente, debemos eliminarlo de la lista activa aquellos elementos que ya no son PS ni RRD. [1] https://lore.kernel.org/netdev/60d274838bf09777f0371253416e8af71360bc08.1633609148.git.dcaratti@redhat.com/ v3: corrige la ejecución entre ets_qdisc_change() y ets_qdisc_dequeue() eliminando las clases de DRR más allá de 'nbands' en c_cambio() con el bloqueo qdisc adquirido, gracias a Cong Wang. v2: cuando se encuentra una qdisc NULL en la lista activa de DRR, intente sacar de la cola a skb del siguiente elemento de la lista.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: Deshabilitar las colas de Tx al reconfigurar la interfaz Las colas de Tx no se deshabilitaron en situaciones en las que el controlador necesitaba detener la interfaz para aplicar una nueva configuración. Esto podría provocar un pánico en el kernel al realizar cualquiera de las 3 acciones siguientes: * reconfigurar el número de colas (ethtool -L) * reconfigurar el tamaño de los búferes circulares (ethtool -G) * instalar/eliminar un programa XDP (ip l set dev ethX xdp) Evite el pánico asegurándose de que se llame a netif_tx_disable al detener una interfaz. Sin este parche, se puede observar el siguiente pánico del kernel al realizar cualquiera de las acciones anteriores: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff80001238d040 [....] Seguimiento de llamadas: dwmac4_set_addr+0x8/0x10 dev_hard_start_xmit+0xe4/0x1ac sch_direct_xmit+ 0xe8/0x39c __dev_queue_xmit+0x3ec/0xaf0 dev_queue_xmit+0x14/0x20 [...] [fin de seguimiento 0000000000000002]---

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.