Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_ct: omitir expectativas para conntrack confirmado nft_ct_expect_obj_eval() llama a nf_ct_ext_add() para una entrada de conntrack confirmada. Sin embargo, nf_ct_ext_add() solo se puede invocar para !nf_ct_is_confirmed(). [1825.349056] ADVERTENCIA: CPU: 0 PID: 1279 en net/netfilter/nf_conntrack_extend.c:48 nf_ct_xt_add+0x18e/0x1a0 [nf_conntrack] [1825.351391] RIP: 0010:nf_ct_ext_add+0x18e/0x 1a0 [nf_conntrack] [ 1825.351493] Código: 41 5c 41 5d 41 5e 41 5f c3 41 bc 0a 00 00 00 e9 15 ff ff ff ba 09 00 00 00 31 f6 4c 89 ff e8 69 6c 3d e9 eb 96 45 31 ed eb cd <0f> 0b e9 b1 fe ff ff e8 86 79 14 e9 eb bf 0f 1f 40 00 0f 1f 44 00 [ 1825.351721] RSP: 0018:ffffc90002e1f1e8 EFLAGS: 00010202 [ 1825.351790] RAX: 00000000000000 0e RBX: ffff88814f5783c0 RCX: ffffffffc0e4f887 [ 1825.351881] RDX: dffffc0000000000 RSI: 00000000000000008 RDI: ffff88814f578440 [ 1825.351971] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88814f578447 [ 1825.352060] R10: ffffed1029eaf088 R11: 00000000000000 01 R12: ffff88814f578440 [ 1825.352150] R13: ffff8882053f3a00 R14: 0000000000000000 R15: 0000000000000a20 [ 1825.352240] FS: 00007f99226 1c900(0000) GS:ffff889faec00000(0000 ) knlGS:0000000000000000 [ 1825.352343] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1825.352417] CR2: 000056070a4d1158 CR3: 00000001 5efe0000 CR4: 0000000000350ee0 [1825.352508] Seguimiento de llamadas: [1825.352544] nf_ct_helper_ext_add+0x10/0x60 [nf_conntrack] [1825.352641 ] nft_ct_expect_obj_eval+0x1b8/0x1e0 [nft_ct] [ 1825.352716] nft_do_chain+0x232/0x850 [nf_tables] Agregue la extensión ct helper solo para conntrack no confirmado. Omita la evaluación de la regla si la extensión ct helper no existe. Por lo tanto, sólo puedes crear expectativas desde el primer paquete. Debería ser posible eliminar esta limitación agregando una nueva acción para adjuntar un asistente ct genérico al primer paquete. Luego, use esta extensión de ayuda de ct de los paquetes de seguimiento para crear la expectativa de ct. Mientras lo hace, agregue una marca faltante para omitir también la plantilla conntrack y elimine la marca IPCT_UNTRACK que está implícita en !ct.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvmet: solución que libera p2pmem no asignado En caso de que se encuentre un dispositivo p2p pero el grupo p2p esté vacío, el objetivo nvme todavía está intentando liberar el sgl del grupo p2p en lugar del sgl normal. pool y provocando un bloqueo (se llama a BUG()). En su lugar, asigne p2p_dev para la solicitud solo si se asignó desde el grupo p2p. Este es el accidente que se provocó: [domingo 30 de mayo 19:13:53 2021] ------------[ cortar aquí ]------------ [domingo de mayo 30 19:13:53 2021] ¡ERROR del kernel en lib/genalloc.c:518! [domingo 30 de mayo 19:13:53 2021] código de operación no válido: 0000 [#1] SMP PTI... [domingo 30 de mayo 19:13:53 2021] ERROR del kernel en lib/genalloc.c:518. ... [dom 30 de mayo 19:13:53 2021] RIP: 0010:gen_pool_free_owner+0xa8/0xb0 ... [dom 30 de mayo 19:13:53 2021] Seguimiento de llamadas: [dom 30 de mayo 19:13:53 2021 ] ------------[ cortar aquí ]------------ [domingo 30 de mayo 19:13:53 2021] pci_free_p2pmem+0x2b/0x70 [domingo 30 de mayo 19 :13:53 2021] pci_p2pmem_free_sgl+0x4f/0x80 [domingo 30 de mayo 19:13:53 2021] nvmet_req_free_sgls+0x1e/0x80 [nvmet] [domingo 30 de mayo 19:13:53 2021] ERROR del kernel en lib/genalloc.c: 518! [dom 30 de mayo 19:13:53 2021] nvmet_rdma_release_rsp+0x4e/0x1f0 [nvmet_rdma] [dom 30 de mayo 19:13:53 2021] nvmet_rdma_send_done+0x1c/0x60 [nvmet_rdma]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrige el use-after-free después de que el dispositivo TLS se cae y se enciende. Cuando un netdev con descarga TLS activa se cae, se llama a tls_device_down para detener la descarga y derribarlo. el contexto TLS. Sin embargo, el socket permanece activo y todavía apunta al contexto TLS, que ahora está desasignado. Si se activa un netdev, mientras la conexión aún está activa, y el flujo de datos se reanuda después de varias retransmisiones TCP, se producirá un use-after-free del contexto TLS. Esta commit soluciona este error manteniendo vivo el contexto hasta su destrucción normal e implementa las alternativas necesarias para que la conexión pueda reanudarse en modo kTLS de software (no descargado). En el lado TX, tls_sw_fallback se utiliza para cifrar todos los paquetes. El lado RX ya tiene todos los respaldos necesarios, porque se admite la recepción de paquetes no descifrados. Lo que se necesita en el lado RX es bloquear las solicitudes de resincronización, que normalmente se producen después de recibir paquetes no descifrados. Se implementa la sincronización necesaria para un desmontaje elegante: primero se implementan los respaldos, luego se liberan los recursos del controlador (antes era posible tener un tls_dev_resync después de tls_dev_del). Se agrega una nueva bandera llamada TLS_RX_DEV_DEGRADED para indicar el modo de reserva. Se utiliza para omitir completamente la lógica de resincronización RX, ya que se vuelve inútil y algunos objetos pueden liberarse (por ejemplo, resync_async, que el controlador asigna y libera).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige la corrupción de sk_forward_memory en la retransmisión El manejo de MPTCP sk_forward_memory es un poco especial, ya que dicho campo está protegido por el socket msk spin_lock, en lugar del bloqueo de socket simple. Actualmente tenemos una ruta de código que actualiza dicho campo sin manejar el bloqueo relevante: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Varios ayudantes en __mptcp_clean_una_wakeup() actualizarán sk_forward_alloc, posiblemente causando dicha corrupción de campo, según lo informado por Matthieu. Solucione el problema proporcionando y utilizando una nueva variante de la función culpada que adquiere explícitamente el bloqueo de giro msk.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: amd_sfh: Reparar pérdida de memoria en amd_sfh_work La herramienta Kmemleak detectó una pérdida de memoria en el controlador amd_sfh. ==================== objeto sin referencia 0xffff88810228ada0 (tamaño 32): comm "insmod", pid 3968, jiffies 4295056001 (edad 775,792 s) volcado hexadecimal (primeros 32 bytes) : 00 20 73 1f 81 88 ff ff 00 01 00 00 00 00 ad de . s................. 22 01 00 00 00 00 ad de 01 00 02 00 00 00 00 00 "................. retroceso: [< 000000007b4c8799>] kmem_cache_alloc_trace+0x163/0x4f0 [<0000000005326893>] amd_sfh_get_report+0xa4/0x1d0 [amd_sfh] [<000000002a9e5ec4>] amdtp_hid_request+0x6 2/0x80 [amd_sfh] [<00000000b8a95807>] sensor_hub_get_feature+0x145/0x270 [hid_sensor_hub] [<00000000fda054ee >] hid_sensor_parse_common_attributes+0x215/0x460 [hid_sensor_iio_common] [<0000000021279ecf>] hid_accel_3d_probe+0xff/0x4a0 [hid_sensor_accel_3d] [<00000000915760ce>] platform_probe+0x6a/0xd0 [ <0000000060258a1f>] very_probe+0x192/0x620 [<00000000fa812f2d>] driver_probe_device+ 0x14a/0x1d0 [<000000005e79f7fd>] __device_attach_driver+0xbd/0x110 [<0000000070d15018>] bus_for_each_drv+0xfd/0x160 [<0000000013a3c312>] __device_attach+0x1 8b/0x220 [<000000008c7b4afc>] dispositivo_sonda_inicial+0x13/0x20 [<00000000e6e99665>] bus_probe_dispositivo+ 0xfe/0x120 [<00000000833fa90b>] device_add+0x6a6/0xe00 [<00000000fa901078>] platform_device_add+0x180/0x380 ===================== La solución es liberar la entrada request_list una vez que la entrada procesada se elimina de request_list.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: efi/fdt: corrige el pánico cuando no se encuentra un fdt válido. setup_arch() invocaría efi_init()->efi_get_fdt_params(). Si no se encuentra un fdt válido, inicial_boot_params será nulo. Por lo tanto, deberíamos detener el procesamiento adicional de fdt aquí. Encontré este problema en risc-v.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: mt7921: solucione un posible problema de AOOB en mt7921_mcu_tx_rate_report. Corrija un posible acceso fuera de los límites a la matriz en mt7921_mcu_tx_rate_report. Eliminar variables innecesarias en mt7921_mcu_tx_rate_report

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vecino: permite forzar las entradas NUD_NOARP. Las interfaces GCed IFF_POINTOPOINT utilizan entradas NUD_NOARP para IPv6. Es posible llenar la tabla de vecinos con suficientes entradas para que después de eso se desborde de conexiones válidas. Este comportamiento es más frecuente después de aplicar el commit 58956317c8de ("vecino: mejorar la recolección de basura"), ya que evita la eliminación de entradas que no son NUD_FAILED, a menos que tengan más de 5 años de antigüedad.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/kvm: deshabilite kvmclock en todas las CPU al apagar Actualmente, deshabilitamos kvmclock desde el enlace machine_shutdown() y esto solo sucede para la CPU de arranque. Necesitamos deshabilitarlo para todas las CPU para protegernos contra la corrupción de la memoria, por ejemplo, al restaurar desde la hibernación. Tenga en cuenta que escribir '0' en kvmclock MSR no borra la ubicación de la memoria, solo evita que el hipervisor actualice la ubicación, por lo que durante un breve período después de la escritura y mientras la CPU aún está activa, el reloj permanece utilizable y correcto, por lo que no lo necesitamos. para cambiar a alguna otra fuente de reloj.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netback: toma una referencia al hilo de la tarea RX. Haga esto para evitar que la tarea se libere si el hilo regresa (que puede ser activado por el frontend) antes de que llamada a kthread_stop realizada como parte del desmontaje del backend. No tomar la referencia conducirá a un use-after-free en ese escenario. Esta referencia se tomó antes, pero se eliminó como parte de la revisión realizada en 2ac061ce97f4. Vuelva a introducir la toma de referencia y agregue esta vez un comentario explicando por qué es necesario. Este es XSA-374/CVE-2021-28691.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/kvm: Desmontaje de funciones PV también en la CPU de arranque Varias funciones PV (Async PF, PV EOI, tiempo de robo) funcionan a través de la memoria compartida con el hipervisor y cuando restauramos desde la hibernación Debemos eliminar adecuadamente todas estas características para asegurarnos de que el hipervisor no escriba en ubicaciones obsoletas después de saltar al kernel previamente hibernado (que puede intentar colocar cualquier cosa allí). Para las CPU secundarias, el trabajo ya lo realiza kvm_cpu_down_prepare(), registre syscore ops para hacer lo mismo para la CPU de arranque.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: abortar en rename_exchange si no logramos insertar la segunda referencia. El error de inyección de estrés descubrió un problema en el que dejaríamos una referencia de inodo colgante si fallábamos durante un rename_exchange. Esto sucede porque insertamos la referencia del inodo para un lado del cambio de nombre y luego para el otro lado. Si esta segunda inserción de referencia de inodo falla, dejaremos el primero colgando y dejaremos un sistema de archivos corrupto. Solucione este problema abortando si hicimos la inserción para la primera referencia de inodo.