Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath10k: corrección del puntero dma_free_coherent()<br /> <br /> dma_alloc_coherent() asigna un búfer mapeado por DMA y almacena las direcciones en campos XXX_unaligned. Esas deberían ser reutilizadas al liberar el búfer en lugar de las direcciones alineadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> slab: corrección de la verificación de contexto de kmalloc_nolock() para PREEMPT_RT<br /> <br /> En kernels PREEMPT_RT, local_lock se convierte en un bloqueo de suspensión. La verificación actual en kmalloc_nolock() solo verifica que no estamos en un contexto NMI o de IRQ dura, pero omite el caso en que la preemption está deshabilitada.<br /> <br /> Cuando un programa BPF se ejecuta desde un tracepoint con la preemption deshabilitada (preempt_count &amp;gt; 0), kmalloc_nolock() procede a llamar a local_lock_irqsave(), que intenta adquirir un bloqueo de suspensión, lo que desencadena:<br /> <br /> BUG: función de suspensión llamada desde contexto inválido<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128<br /> preempt_count: 2, esperado: 0<br /> <br /> Solucione esto verificando !preemptible() en PREEMPT_RT, lo que expresa directamente la restricción de que no podemos tomar un bloqueo de suspensión cuando la preemption está deshabilitada. Esto abarca las verificaciones anteriores para contextos NMI e IRQ dura, al mismo tiempo que detecta casos en los que la preemption está deshabilitada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath12k: corrección del puntero dma_free_coherent()<br /> <br /> dma_alloc_coherent() asigna un búfer mapeado por DMA y almacena las direcciones en campos XXX_unaligned. Esas deberían ser reutilizadas al liberar el búfer en lugar de las direcciones alineadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: restablecer el estado de lectura dispersa en osd_fault()<br /> <br /> Cuando ocurre un fallo, la conexión es abandonada, restablecida, y cualquier operación pendiente es reintentada. El cliente OSD rastrea el progreso de una respuesta de lectura dispersa usando una máquina de estados separada, en gran medida independiente del estado del mensajero.<br /> <br /> Si se pierde una conexión a mitad de la carga útil o la máquina de estados de lectura dispersa devuelve un error, el estado de lectura dispersa no se restablece. El cliente OSD interpretará entonces el comienzo de una nueva respuesta como la continuación de la antigua. Si esto hace que la maquinaria de lectura dispersa entre en un estado de fallo, puede que nunca se recupere, produciendo bucles como:<br /> <br /> libceph: [0] got 0 extents<br /> libceph: data len 142248331 != extent len 0<br /> libceph: osd0 (1)...:6801 socket error on read<br /> libceph: data len 142248331 != extent len 0<br /> libceph: osd0 (1)...:6801 socket error on read<br /> <br /> Por lo tanto, restablecer el estado de lectura dispersa en osd_fault(), asegurando que los reintentos comiencen desde un estado limpio.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> of: unittest: Corrección de fuga de memoria en unittest_data_add()<br /> <br /> En unittest_data_add(), si of_resolve_phandles() falla, el unittest_data asignado no se libera, lo que provoca una fuga de memoria.<br /> <br /> Esto se soluciona usando un ayudante de limpieza basado en el ámbito __free(kfree) para la limpieza automática de recursos. Esto asegura que unittest_data se libera automáticamente cuando sale del ámbito en rutas de error.<br /> <br /> Para la ruta de éxito, use retain_and_null_ptr() para transferir la propiedad de la memoria al árbol de dispositivos y evitar la doble liberación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rastreo: Añadir protección contra recursión en la grabación de trazas de pila del kernel<br /> <br /> Se informó de un error sobre una recursión infinita causada por el rastreo de los eventos rcu con el disparador de traza de pila del kernel habilitado. El código de traza de pila volvió a llamar a RCU, que luego volvió a llamar a la traza de pila.<br /> <br /> Expandir la protección contra recursión de ftrace para añadir un conjunto de bits para proteger los eventos de la recursión. Cada bit representa el contexto en el que se encuentra el evento (normal, softirq, interrupción y NMI).<br /> <br /> Hacer que el código de traza de pila use el contexto de interrupción para proteger contra la recursión.<br /> <br /> Nota, el error mostró un problema tanto en el código RCU como en el código de traza de pila de rastreo. Esto solo aborda el lado de la traza de pila de rastreo del error. La corrección de RCU se manejará por separado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: nf_conncount: actualizar last_gc solo cuando se ha realizado la GC<br /> <br /> Actualmente, last_gc se actualiza cada vez que se rastrea una nueva conexión, lo que significa que se actualiza incluso si no se realizó una GC. Con una tasa de paquetes suficientemente alta, es posible eludir siempre la GC, haciendo que la lista crezca infinitamente.<br /> <br /> Actualizar el valor de last_gc solo cuando se ha realizado realmente una GC.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfs: Solución para el desbloqueo temprano de lectura de página con EOF en el medio<br /> <br /> La recopilación de resultados de lectura para lecturas en búfer parece adelantarse a la finalización de las subpeticiones bajo algunas circunstancias, como se puede ver en el siguiente fragmento de registro:<br /> <br /> 9p_client_res: cliente 18446612686390831168 response P9_TREAD tag 0 err 0<br /> ...<br /> netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0<br /> ...<br /> netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2<br /> netfs_folio: i=157f3 ix=00004-00004 read-done<br /> netfs_folio: i=157f3 ix=00004-00004 read-unlock<br /> netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2<br /> netfs_folio: i=157f3 ix=00005-00005 read-done<br /> netfs_folio: i=157f3 ix=00005-00005 read-unlock<br /> ...<br /> netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff<br /> netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c<br /> netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff<br /> netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8<br /> ...<br /> netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0<br /> netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0<br /> <br /> El &amp;#39;cto=5fb2&amp;#39; indica la posición de archivo recopilada a la que hemos recogido resultados hasta ahora, pero aún nos quedan 0x4e bytes más, por lo que no deberíamos haber recopilado el folio ix=00005 todavía. La subpetición &amp;#39;ZERO&amp;#39; que borra la cola ocurre después de que desbloqueamos el folio, permitiendo que la aplicación vea la cola no borrada a través de mmap.<br /> <br /> El problema es que netfs_read_unlock_folios() desbloqueará un folio en el que la cantidad de resultados de lectura recopilados alcanza la posición EOF, pero la subpetición ZERO se encuentra más allá de eso y, por lo tanto, ocurre después.<br /> <br /> Solucione esto cambiando la comprobación de fin para que siempre sea el fin del folio y nunca el fin del archivo.<br /> <br /> En el futuro, debería considerar borrar hasta el final del folio aquí en lugar de añadir una subpetición ZERO para hacer esto. Por otro lado, la subpetición ZERO puede ejecutarse en paralelo con una subpetición READ asíncrona. Además, la subpetición ZERO aún puede ser necesaria para, por ejemplo, manejar extensiones en un archivo ceph que no tienen ningún almacenamiento de respaldo y, por lo tanto, son implícitamente todo ceros.<br /> <br /> Esto se puede reproducir creando un archivo cuyo tamaño no se alinea con un límite de página, por ejemplo, 24998 (0x5fb2) bytes, y luego haciendo algo como:<br /> <br /> xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \<br /> -c "mread -v 0 0x6000" /xfstest.test/x<br /> <br /> Los últimos 0x4e bytes deberían ser todos 00, pero si la cola no ha sido borrada todavía, es posible que vea basura allí. Esto se puede reproducir con kafs modificando el kernel para deshabilitar la llamada a netfs_read_subreq_progress() y para evitar que afs_issue_read() realice la llamada asíncrona para NETFS_READAHEAD. La reproducción se puede facilitar insertando un mdelay(100) en netfs_issue_read() para el caso de la subpetición ZERO.<br /> <br /> AFS y CIFS normalmente no suelen mostrar esto, ya que despachan operaciones READ de forma asíncrona, lo que permite que la subpetición ZERO termine primero. La operación READ de 9P es completamente síncrona, por lo que la subpetición ZERO siempre ocurrirá después. Sin embargo, no se ve todo el tiempo, porque la recopilación puede realizarse en un hilo de trabajo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iommu/sva: invalidar entradas IOTLB obsoletas para el espacio de direcciones del kernel<br /> <br /> Se introduce una nueva interfaz IOMMU para vaciar las entradas de la caché de paginación IOTLB para el espacio de direcciones del kernel de la CPU. Esta interfaz se invoca desde el código de arquitectura x86 que gestiona las tablas de páginas combinadas de usuario y kernel, específicamente antes de que cualquier página de tabla de páginas del kernel sea liberada y reutilizada.<br /> <br /> Esto aborda el problema principal con vfree(), que es una ocurrencia común y puede ser activado por usuarios no privilegiados. Si bien esto resuelve el problema principal, no aborda un caso extremadamente raro relacionado con la desconexión de memoria que estaba presente como memoria reservada en el arranque, que no puede ser activado por usuarios no privilegiados. La discusión se puede encontrar en el enlace a continuación.<br /> <br /> Habilitar SVA en la arquitectura x86 ya que la IOMMU ahora puede recibir notificación para vaciar la caché de paginación antes de liberar las páginas de la tabla de páginas del kernel de la CPU.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> arm64: Establecer __nocfi en swsusp_arch_resume()<br /> <br /> Se informa de un DABT[1] en un sistema basado en Android al reanudar desde la hibernación. Esto ocurre porque swsusp_arch_suspend_exit() está marcado con SYM_CODE_*() y no tiene un hash CFI, pero swsusp_arch_resume() intentará verificar el hash CFI al llamar a una copia de swsusp_arch_suspend_exit().<br /> <br /> Dado que existe un requisito de que el punto de entrada a swsusp_arch_suspend_exit() es el primer byte de la sección .hibernate_exit.text, no podemos solucionar esto marcando swsusp_arch_suspend_exit() con SYM_FUNC_*(). La solución más sencilla por ahora es deshabilitar la verificación CFI en swsusp_arch_resume().<br /> <br /> Marcar swsusp_arch_resume() como __nocfi para deshabilitar la verificación CFI.<br /> <br /> [1]<br /> [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc<br /> [ 22.991934][ T1] Mem abort info:<br /> [ 22.991934][ T1] ESR = 0x0000000096000007<br /> [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 22.991934][ T1] SET = 0, FnV = 0<br /> [ 22.991934][ T1] EA = 0, S1PTW = 0<br /> [ 22.991934][ T1] FSC = 0x07: level 3 translation fault<br /> [ 22.991934][ T1] Data abort info:<br /> [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000<br /> [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper<br /> [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP<br /> [ 22.991934][ T1] Dumping ftrace buffer:<br /> [ 22.991934][ T1] (ftrace buffer empty)<br /> [ 22.991934][ T1] Modules linked in:<br /> [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419<br /> [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT)<br /> [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344<br /> [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344<br /> [ 22.991934][ T1] sp : ffffffc08006b960<br /> [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820<br /> [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000<br /> [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058<br /> [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004<br /> [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000<br /> [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000<br /> [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b<br /> [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530<br /> [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000<br /> [ 22.991934][ T1] Call trace:<br /> [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344<br /> [ 22.991934][ T1] hibernation_restore+0x158/0x18c<br /> [ 22.991934][ T1] load_image_and_restore+0xb0/0xec<br /> [ 22.991934][ T1] software_resume+0xf4/0x19c<br /> [ 22.991934][ T1] software_resume_initcall+0x34/0x78<br /> [ 22.991934][ T1] do_one_initcall+0xe8/0x370<br /> [ 22.991934][ T1] do_initcall_level+0xc8/0x19c<br /> [ 22.991934][ T1] do_initcalls+0x70/0xc0<br /> [ 22.991934][ T1] do_basic_setup+0x1c/0x28<br /> [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148<br /> [ 22.991934][ T1] kernel_init+0x20/0x1a8<br /> [ 22.991934][ T1] ret_from_fork+0x10/0x20<br /> [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)<br /> <br /> [catalin.marinas@arm.com: commit log updated by Mark Rutland]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dpll: Prevenir registros duplicados<br /> <br /> Modificar las funciones auxiliares de registro internas dpll_xa_ref_{dpll,pin}_add() para rechazar intentos de registro duplicados.<br /> <br /> Anteriormente, si un llamador intentaba registrar el mismo pin múltiples veces (con las mismas ops, priv y cookie) en el mismo dispositivo, el núcleo incrementaba silenciosamente el contador de referencias y devolvía éxito. Este comportamiento es incorrecto porque si el llamador realiza estos registros duplicados, entonces para el primero se asigna dpll_pin_registration y para los demás se incrementa el dpll_pin_ref.refcount asociado. Durante la primera anulación de registro se libera el dpll_pin_registration asociado y para los demás se dispara una advertencia.<br /> <br /> Esto se soluciona actualizando la lógica para devolver -EEXIST si se encuentra un registro coincidente, para aplicar una política estricta de &amp;#39;registrar una vez&amp;#39;.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> wifi: ath12k: solucionar interbloqueo al vaciar tramas de gestión<br /> <br /> El commit [1] convirtió el elemento de trabajo de transmisión de gestión en un trabajo wiphy. Dado que un trabajo wiphy solo puede ejecutarse bajo la protección del bloqueo wiphy, ocurre una condición de carrera en el siguiente escenario:<br /> <br /> 1. una trama de gestión se pone en cola para transmisión.<br /> 2. se llama a ath12k_mac_op_flush() para vaciar las tramas pendientes asociadas con el hardware (es decir, vif es NULL). Luego, en ath12k_mac_flush(), el proceso espera a que la transmisión finalice.<br /> 3. Dado que el bloqueo wiphy ha sido tomado por el proceso de vaciado, el elemento de trabajo de transmisión no tiene oportunidad de ejecutarse, de ahí el interbloqueo.<br /> <br /> Desde la perspectiva del usuario, este interbloqueo resulta en el siguiente problema:<br /> <br /> wlp8s0: autenticar con xxxxxx (dirección local=xxxxxx)<br /> wlp8s0: enviar autenticación a xxxxxx (intento 1/3)<br /> wlp8s0: autenticar con xxxxxx (dirección local=xxxxxx)<br /> wlp8s0: enviar autenticación a xxxxxx (intento 1/3)<br /> wlp8s0: autenticado<br /> wlp8s0: asociar con xxxxxx (intento 1/3)<br /> wlp8s0: abortando asociación con xxxxxx por elección local (Razón: 3=DEAUTH_LEAVING)<br /> ath12k_pci 0000:08:00.0: falló al vaciar la cola de transmisión de gestión, paquetes de gestión pendientes 1<br /> <br /> El interbloqueo puede evitarse invocando wiphy_work_flush() para ejecutar proactivamente el elemento de trabajo en cola. Nótese que en realidad ya está presente en ath12k_mac_op_flush(), sin embargo, no protege el caso en que vif es NULL. Por lo tanto, se mueve hacia adelante para cubrir también este caso.<br /> <br /> Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3