Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvmet: corregir condición de carrera en nvmet_bio_done() que lleva a una desreferencia de puntero NULL<br /> <br /> Existe una condición de carrera en nvmet_bio_done() que puede causar una desreferencia de puntero NULL en blk_cgroup_bio_start():<br /> <br /> 1. nvmet_bio_done() es llamada cuando un bio se completa<br /> 2. nvmet_req_complete() es llamada, lo que invoca req-&amp;gt;ops-&amp;gt;queue_response(req)<br /> 3. La devolución de llamada queue_response puede volver a encolar y volver a enviar la misma solicitud<br /> 4. El reenvío reutiliza el mismo inline_bio de nvmet_req<br /> 5. Mientras tanto, nvmet_req_bio_put() (llamada después de nvmet_req_complete) invoca bio_uninit() para inline_bio, lo que establece bio-&amp;gt;bi_blkg en NULL<br /> 6. El bio reenviado entra en submit_bio_noacct_nocheck()<br /> 7. blk_cgroup_bio_start() desreferencia bio-&amp;gt;bi_blkg, causando un fallo:<br /> <br /> ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000028<br /> #PF: acceso de lectura de supervisor en modo kernel<br /> RIP: 0010:blk_cgroup_bio_start+0x10/0xd0<br /> Rastro de Llamada:<br /> submit_bio_noacct_nocheck+0x44/0x250<br /> nvmet_bdev_execute_rw+0x254/0x370 [nvmet]<br /> process_one_work+0x193/0x3c0<br /> worker_thread+0x281/0x3a0<br /> <br /> Corregir esto reordenando nvmet_bio_done() para llamar a nvmet_req_bio_put() ANTES de nvmet_req_complete(). Esto asegura que el bio se limpie antes de que la solicitud pueda ser reenviada, previniendo la condición de carrera.

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 /> 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 /> 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: 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 /> drm/bridge: synopsys: dw-dp: corregir rutas de error de dw_dp_bind<br /> <br /> Corregir varios problemas en el manejo de errores de dw_dp_bind():<br /> <br /> 1. Retorno faltante después de un fallo de drm_bridge_attach(): la función continuó la ejecución en lugar de devolver un error.<br /> <br /> 2. Fuga de recursos: drm_dp_aux_register() no es una función devm, por lo que drm_dp_aux_unregister() debe ser llamada en todas las rutas de error después de que el registro auxiliar tenga éxito. Esto afecta a los errores de:<br /> - drm_bridge_attach()<br /> - phy_init()<br /> - devm_add_action_or_reset()<br /> - platform_get_irq()<br /> - devm_request_threaded_irq()<br /> <br /> 3. Corrección de error: platform_get_irq() devuelve el número IRQ o un código de error negativo, pero la ruta de error estaba devolviendo ERR_PTR(ret) en lugar de ERR_PTR(dp-&amp;gt;irq).<br /> <br /> Usar una etiqueta goto para la limpieza para asegurar un manejo de errores consistente.

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 /> 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 /> 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 /> 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 /> 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 /> platform/x86: hp-bioscfg: Corrección de advertencias de kobject para nombres de atributos vacíos<br /> <br /> El controlador hp-bioscfg intenta registrar kobjects con nombres vacíos cuando la BIOS de HP devuelve atributos con cadenas de nombre vacías. Esto causa múltiples advertencias del kernel:<br /> <br /> kobject: (00000000135fb5e6): ¡se intentó registrar con nombre vacío!<br /> WARNING: CPU: 14 PID: 3336 en lib/kobject.c:219 kobject_add_internal+0x2eb/0x310<br /> <br /> Añadir validación en hp_init_bios_buffer_attribute() para verificar si el nombre del atributo está vacío después de analizarlo desde el búfer WMI. Si está vacío, registrar un mensaje de depuración y omitir el registro de ese atributo, permitiendo que el módulo continúe procesando otros atributos válidos.