Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige la advertencia de UBSAN en kv_dpm.c Agrega verificación de los límites para sumo_vid_mapping_entry.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/radeon: corrige la advertencia de UBSAN en kv_dpm.c Agrega verificación de los límites para sumo_vid_mapping_entry.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: desasociar vcpus de la región del redistribuidor al desmantelar Al desmantelar una región de redistribuidor, asegúrese de que no tengamos ningún puntero colgante a esa región almacenado en una vcpu.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mlx5: Agregar verificación para el atributo srq max_sge El usuario pasa el atributo max_sge, se inserta y se usa sin marcar, así que verifique que el valor no exceda el valor máximo permitido antes usándolo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: ipset: corrige rcu_dereference_protected() sospechoso Al destruir todos los conjuntos, estamos en la fase de salida de pernet o estamos ejecutando un "comando de destruir todos los conjuntos" desde el espacio de usuario. Este último se tuvo en cuenta en ip_set_dereference() (se mantiene el mutex de nfnetlink), pero el primero no. El parche agrega la verificación requerida a rcu_dereference_protected() en ip_set_dereference().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: corrige el desbordamiento de enteros en max_vclocks_store En sistemas de 32 bits, la multiplicación "4 * max" puede desbordarse. Utilice kcalloc() para realizar la asignación y evitar esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_api: corrige posible bucle infinito en tcf_idr_check_alloc() syzbot encontró tareas pendientes esperando en rtnl_lock [1] Hay un reproductor disponible en el error syzbot. Cuando se envía una solicitud para agregar varias acciones con el mismo índice, la segunda solicitud se bloqueará para siempre en la primera solicitud. Esto retiene rtnl_lock y hace que las tareas se bloqueen. Devuelve -EAGAIN para evitar bucles infinitos y al mismo tiempo mantener el comportamiento documentado. [1] INFORMACIÓN: tarea kworker/1:0:5088 bloqueada durante más de 143 segundos. No contaminado 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:kworker/1:0 estado:D pila:23744 pid:5088 tgid:5088 ppid:2 banderas:0x00004000 Cola de trabajo: events_power_ficient reg_check_chans_work Seguimiento de llamadas: context_switch kernel/sched/core.c:5409 [en línea] __schedule+ 0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 programación [en línea]+0xe7/0x350 kernel/sched/core.c:6838 Schedule_preempt_disabled+0x13/0x30 kernel/sched/core. c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [en línea] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [en línea] reg_leave_invalid_chans net/wireless/reg. c:2466 [en línea] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: evitar splat en pskb_pull_reason compilaciones de syzkaller (CONFIG_DEBUG_NET=y) frecuentemente activa una sugerencia de depuración en pskb_may_pull. Nos gustaría conservar esta verificación de depuración porque podría indicar desbordamientos de enteros y otros problemas (el código del kernel debe extraer encabezados, no valores enormes). En el caso de bpf, este símbolo no es nada interesante: estos programas bpf (sin sentido) normalmente son generados por un fuzzer de todos modos. Haga lo que Eric sugirió y suprima esa advertencia. Para CONFIG_DEBUG_NET=n no necesitamos la verificación adicional porque pskb_may_pull hará lo correcto: devolver un error sin el rastreo WARN().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: plataforma/x86: x86-android-tablets: cancelar el registro de dispositivos en orden inverso. No todos los subsistemas admiten la eliminación de un dispositivo mientras todavía hay consumidores del dispositivo con una referencia al dispositivo. Un ejemplo de esto es el subsistema regulador. Si un regulador se da de baja mientras todavía hay controladores que tienen una referencia, se activa WARN() en drivers/regulator/core.c:5829, por ejemplo: ADVERTENCIA: CPU: 1 PID: 1587 en drivers/regulator/core.c:5829 regulator_unregister Nombre del hardware: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 10/04/2015 RIP: 0010:regulator_unregister Seguimiento de llamada: regulator_unregister i2c_device_remove devres_release_group device_release_driver_internal device_del device_unregister x86_android_tablet_remove En la serie Lenovo Yoga Tablet 2, el chip del cargador bq24190 también proporciona una salida de convertidor elevador de 5 V para alimentar dispositivos USB conectados al puerto micro USB; el controlador del cargador bq24190 lo exporta como un regulador Vbus. En los modelos 830 (8") y 1050 ("10"), este regulador está controlado por un platform_device y x86_android_tablet_remove() elimina platform_device-s antes que i2c_clients para que el consumidor se elimine primero. Pero en el modelo 1380 (13") hay un interruptor micro-USB lc824206xa conectado a través de I2C y el controlador externo que controla el regulador. El cliente i2c bq24190 *debe* registrarse primero, porque eso crea el regulador con el lc824206xa listado como su consumidor. Si el regulador aún no se ha registrado, el controlador lc824206xa terminará obteniendo un regulador ficticio. Dado que en este caso tanto el proveedor del regulador como el consumidor son dispositivos I2C, la única forma de garantizar que el consumidor cancele el registro primero es cancelar el registro de los dispositivos I2C en el orden inverso al que fueron creados. Para mantener la coherencia y evitar problemas similares en el futuro, cambie x86_android_tablet_remove() para cancelar el registro de todos los tipos de dispositivos en orden inverso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: soluciona el fallo del kernel durante la reanudación Actualmente, durante la reanudación, la memoria de destino de QMI no se maneja adecuadamente, lo que provoca un fallo del kernel en caso de que no se admita la reasignación de DMA: ERROR: Estado incorrecto de la página en proceso kworker/u16:54 pfn:36e80 página: refcount:1 mapcount:0 mapeo:0000000000000000 index:0x0 pfn:0x36e80 página descargada porque: distinto de cero _refcount Rastreo de llamadas: bad_page free_page_is_bad_report __free_pages_ok __free_pages dma_direct_free dma_free_attrs a th12k_qmi_free_target_mem_chunk ath12k_qmi_msg_mem_request_cb El motivo es: Una vez ath12k El módulo está cargado, el firmware envía la solicitud de memoria al host. En caso de que no se admita la reasignación de DMA, ath12k rechaza la primera solicitud debido a un error en la asignación con un tamaño de segmento grande: ath12k_pci 0000:04:00.0: solicitud de firmware qmi solicitud de memoria ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 7077888 ath12k_pci 0000 :04:00.0: qmi mem seg tipo 4 tamaño 8454144 ath12k_pci 0000:04:00.0: falla en la asignación de qmi dma (7077888 B tipo 1), lo intentaré más tarde con un tamaño pequeño ath12k_pci 0000:04:00.0: qmi retrasa mem_request 2 ath12k_pci 0000: 04:00.0: solicitud de memoria de solicitud de firmware qmi El firmware posterior regresa con más segmentos, pero pequeños, y la asignación se realiza correctamente: ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 pci 0000:04:00.0:qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 262144 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000 :04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00 .0: segmento de memoria qmi tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 24288 ath12k_pci 0000:04 :00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 5242 88 ath12k_pci 0000:04:00.0 : qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem se g tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 65536 ci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 Ahora ath12k está funcionando. Si se activa la suspensión, el firmware se recargará durante la reanudación. Al igual que antes, el firmware solicita dos segmentos grandes al principio. En ath12k_qmi_msg_mem_request_cb() se asigna el recuento y el tamaño del segmento: ab->qmi.mem_seg_count == 2 ab->qmi.target_mem[0].size == 7077888 ab->qmi.target_mem[1].size == 8454144 Luego, la asignación falló como antes y se llama a ath12k_qmi_free_target_mem_chunk() para liberar todos los segmentos asignados. ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ssb: corrige la posible desreferencia del puntero NULL en ssb_device_uevent() La función ssb_device_uevent() primero intenta convertir el puntero 'dev' en 'struct ssb_device *'. Sin embargo, por error elimina la referencia a 'dev' antes de realizar la comprobación NULL, lo que podría provocar una desreferencia del puntero NULL si 'dev' es NULL. Para solucionar este problema, mueva la marca NULL antes de eliminar la referencia al puntero 'dev', asegurándose de que el puntero sea válido antes de intentar usarlo. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/lima: enmascara irqs en la ruta de tiempo de espera antes del restablecimiento completo. Existe una condición de ejecución en la que un trabajo de renderizado puede tardar el tiempo suficiente para activar el controlador de tiempo de espera del trabajo programado drm, pero también completar antes de que el controlador de tiempo de espera realice el restablecimiento completo. Esto se encuentra con condiciones de ejecución que el controlador de tiempo de espera no esperaba. En algunos casos muy específicos, actualmente puede resultar en un desequilibrio de recuento en lima_pm_idle, con un volcado de pila como: [10136.669170] ADVERTENCIA: CPU: 0 PID: 0 en drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+ 0xa0/0xb0... [10136.669459] pc: lima_devfreq_record_idle+0xa0/0xb0... [10136.669628] Rastreo de llamadas: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_tas k_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [ 10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 Podemos evitar esa condición de ejecución por completo enmascarando los irqs al comienzo del controlador de tiempo de espera, momento en el cual renunciamos a esperar por ese trabajo por completo. Los irqs se habilitarán nuevamente en el próximo restablecimiento completo, que ya se realiza como recuperación mediante el controlador de tiempo de espera.