Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/hdcp: Agregar comprobación del codificador en hdcp2_get_capability Agregar comprobación del codificador en intel_hdcp2_get_capability para evitar un error de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: evitar la desreferenciación de punteros NULL si no se admite ATIF acpi_evaluate_object() puede devolver AE_NOT_FOUND (error), lo que provocaría la desreferenciación de buffer.pointer (obj) mientras sea NULL. Aunque este caso puede ser poco realista para el código actual, sigue siendo mejor protegerse contra posibles errores. También se debe abandonar cuando el estado sea AE_NOT_FOUND. Esto soluciona 1 problema de FORWARD_NULL informado por Coverity Report: CID 1600951: Desreferencias de punteros nulos (FORWARD_NULL) (seleccionado de el commit 91c9e221fe2553edf2db71627d8453f083de87a1)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: Se ha corregido el manejo de respuestas en iwl_mvm_send_recovery_cmd() 1. No se valida el tamaño del paquete de respuesta. 2. No se libera el búfer de respuesta. Resuelva estos problemas cambiando a iwl_mvm_send_cmd_status(), que maneja tanto la validación del tamaño como la liberación del búfer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: stop qdisc_tree_reduce_backlog en TC_H_ROOT En qdisc_tree_reduce_backlog, se supone que las Qdisc con el identificador principal ffff: son raíz o de entrada. Esta suposición es falsa ya que es válido crear qdiscs de salida con el identificador principal ffff: Budimir Markovic descubrió que para las qdisc como DRR que mantienen una lista de clases activa, provocará un UAF con un puntero de clase colgante. En 066a3b5b2346, la preocupación era evitar iterar sobre la qdisc de entrada ya que su padre es ella misma. La solución adecuada es detener cuando se alcanza el padre TC_H_ROOT porque la única forma de recuperar la entrada es cuando una jerarquía que no contiene un identificador principal ffff: llama a qdisc_lookup con TC_H_MAJ(TC_H_ROOT). En el escenario donde el ffff principal es una qdisc de salida en cualquiera de los niveles del árbol, las actualizaciones también se propagarán a TC_H_ROOT, donde luego la iteración debe detenerse. net/sched/sch_api.c | 2 +- 1 archivo modificado, 1 inserción(+), 1 eliminación(-)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: s5p-jpeg: evitar desbordamientos de búfer La lógica actual permite que word sea menor que 2. Si esto sucede, habrá desbordamientos de búfer, como lo informa smatch. Agregue verificaciones adicionales para evitarlo. Mientras esté aquí, elimine una asignación word = 0 sin usar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrección del fallo en la sonda para LOM E810 con DPLL habilitado El diseño de la placa base Lan On (LOM) E810 es específico del proveedor. Intel proporciona el diseño de referencia, pero el diseño del producto final depende del proveedor. En algunos casos, como el soporte de DPLL para Linux, los valores estáticos definidos en el controlador no reflejan el diseño real de la LOM. La implementación actual de los pines dpll está provocando el fallo en la sonda del controlador ice para dichos diseños de LOM E810 con DPLL habilitado: ADVERTENCIA: (...) en drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Seguimiento de llamadas: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? La cantidad de pines dpll habilitados por el proveedor de LOM es mayor que la esperada y definida en el controlador para las NIC diseñadas por Intel, lo que causa el bloqueo. Evite el bloqueo y permita la inicialización de pines genéricos dentro del subsistema DPLL de Linux para los diseños LOM E810 habilitados para DPLL. La solución recientemente diseñada para el problema descrito se basará en la inicialización de pines "según el diseño de HW". Requiere información de pin adquirida dinámicamente desde el firmware y ya está en progreso, planificado solo para el siguiente árbol.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: init: proteger sched con rcu_read_lock Habilitar CONFIG_PROVE_RCU_LIST con su dependencia CONFIG_RCU_EXPERT crea este splat cuando se crea un socket MPTCP: ============================= ADVERTENCIA: uso sospechoso de RCU 6.12.0-rc2+ #11 No contaminado ----------------------------- net/mptcp/sched.c:44 ¡Lista de RCU recorrida en una sección que no es de lectura! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 no hay bloqueos retenidos por mptcp_connect/176. seguimiento de pila: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect No contaminado 6.12.0-rc2+ #11 Nombre del hardware: Bochs Bochs, BIOS Bochs 01/01/2011 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminador 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminador 1)) ? __sock_create (include/linux/rcupdate.h:347 (discriminador 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Esto se debe a que cuando se inicializa el socket, no se utiliza rcu_read_lock() a pesar del comentario explícito escrito encima de la declaración de mptcp_sched_find() en sched.c. Agregar el bloqueo/desbloqueo faltante evita la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/bpf: utiliza una cola de trabajo dedicada para la destrucción de bpf de cgroup Se encontró un problema hung_task que se muestra a continuación: INFORMACIÓN: la tarea kworker/0:0:8 se bloqueó durante más de 327 segundos. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. Cola de trabajo: eventos cgroup_bpf_release Rastreo de llamadas: __schedule+0x5a2/0x2050 ? find_held_lock+0x33/0x100 ? wq_worker_sleeping+0x9e/0xe0 schedule+0x9f/0x180 schedule_preempt_disabled+0x25/0x50 __mutex_lock+0x512/0x740 ? cgroup_bpf_release+0x1e/0x4d0 ? cgroup_bpf_release+0xcf/0x4d0 ? proceso_trabajos_programados+0x161/0x8a0 ? cgroup_bpf_release+0x1e/0x4d0 ? mutex_lock_nested+0x2b/0x40 ? __pfx_delay_tsc+0x10/0x10 mutex_lock_nested+0x2b/0x40 cgroup_bpf_release+0xcf/0x4d0 ? proceso_trabajos_programados+0x161/0x8a0 ? trace_event_raw_event_workqueue_execute_start+0x64/0xd0 ? Este problema se puede reproducir con la siguiente prueba pressuse: 1. Se elimina una gran cantidad de cgroups de cpuset. 2. Enciende y apaga la CPU repetidamente. 3. Establece watchdog_thresh repetidamente. Los scripts se pueden obtener en el ENLACE mencionado arriba de la firma. El motivo de este problema es que cgroup_mutex y cpu_hotplug_lock se adquieren en tareas diferentes, lo que puede provocar un bloqueo. Puede provocar un bloqueo mediante los siguientes pasos: 1. Se elimina una gran cantidad de conjuntos de CPU de forma asincrónica, lo que coloca una gran cantidad de trabajos cgroup_bpf_release en system_wq. El max_active de system_wq es WQ_DFL_ACTIVE(256). En consecuencia, todos los trabajos activos son trabajos cgroup_bpf_release y muchos trabajos cgroup_bpf_release se colocarán en la cola inactiva. Como se ilustra en el diagrama, hay 256 (en la cola activa) + n (en la cola inactiva) trabajos. 2. La configuración de watchdog_thresh mantendrá cpu_hotplug_lock.read y colocará el trabajo smp_call_on_cpu en system_wq. Sin embargo, el paso 1 ya ha llenado system_wq, 'sscs.work' se coloca en la cola inactiva. 'sscs.work' tiene que esperar hasta que los trabajos que se colocaron en la cola inactiva anteriormente se hayan ejecutado (n cgroup_bpf_release), por lo que se bloqueará por un tiempo. 3. La CPU sin conexión requiere cpu_hotplug_lock.write, que está bloqueado por el paso 2. 4. Los conjuntos de CPU que se eliminaron en el paso 1 colocan los trabajos de cgroup_release en cgroup_destroy_wq. Están compitiendo para obtener cgroup_mutex todo el tiempo. Cuando cgroup_metux es adquirido por un trabajo en css_killed_work_fn, llamará a cpuset_css_offline, que necesita adquirir cpu_hotplug_lock.read. Sin embargo, cpuset_css_offline se bloqueará para el paso 3. 5. En este momento, hay 256 trabajos en la cola activa que son cgroup_bpf_release, están intentando adquirir cgroup_mutex y, como resultado, todos ellos están bloqueados. En consecuencia, no se puede ejecutar sscs.work. En definitiva, esta situación provoca el bloqueo de cuatro procesos, lo que genera un punto muerto. system_wq(paso1) WatchDog(paso2) cpu offline(paso3) cgroup_destroy_wq(paso4) ... 2000+ cgroups eliminados asyn 256 activos + n inactivos __lockup_detector_reconfigure P(cpu_hotplug_lock.read) poner sscs.work en system_wq 256 + n + 1(sscs.work) sscs.work esperar a ser ejecutado warting sscs.work finalizar percpu_down_write P(cpu_hotplug_lock.write) ...bloqueando... css_killed_work_fn P(cgroup_mutex) cpuset_css_offline P(cpu_hotplug_lock.read) ...bloqueando... 256 cgroup_bpf_release mutex_lock(&cgroup_mutex); ..bloqueo... Para solucionar el problema, coloque los trabajos de cgroup_bpf_release en una cola de trabajo dedicada que pueda romper el bucle y resolver el problema. Las colas de trabajo del sistema son para cosas diversas que no deberían crear una gran cantidad de elementos de trabajo simultáneos. Si algo va a generar > ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: slub/kunit: se corrige una ADVERTENCIA debido a que __kmalloc_cache_noprof sin encapsular 'modprobe slub_kunit' tendrá una advertencia como la que se muestra a continuación. La causa principal es que se utilizó __kmalloc_cache_noprof directamente, lo que resultó en que no se asignara alloc_tag. Esto provocó que current->alloc_tag fuera nulo, lo que generó una advertencia en alloc_tag_add_check. Agreguemos una capa alloc_hook a __kmalloc_cache_noprof específicamente dentro de lib/slub_kunit.c, que es el único usuario de esta función slub interna fuera de la implementación de kmalloc en sí. [58162.947016] ADVERTENCIA: CPU: 2 PID: 6210 en ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Rastreo de llamadas: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/rw: se corrige la comprobación NOWAIT faltante para el inicio de escritura O_DIRECT Cuando io_uring inicia una escritura, llamará a kiocb_start_write() para impulsar el rwsem del superbloque, evitando que se produzcan congelamientos mientras esa escritura está en curso. El lado de congelamiento tomará ese rwsem para escribir, excluyendo que se produzcan nuevos escritores y esperando a que finalicen las escrituras existentes. Pero io_uring usa incondicionalmente kiocb_start_write(), que se bloqueará si alguien está intentando congelar el punto de montaje. Esto provoca un punto muerto en el que el congelamiento espera a que se completen las escrituras anteriores, pero las escrituras anteriores no se pueden completar, ya que la tarea que se supone que debe completarlas está bloqueada esperando a iniciar una nueva escritura. Esto da como resultado el siguiente seguimiento atascado que muestra que la dependencia con la escritura bloqueó el inicio de una nueva escritura: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Seguimiento de llamadas: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invocar_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFORMACIÓN: tarea fsfreeze:7364 bloqueada durante más de 15 segundos. No contaminado 6.12.0-rc5-00063-g76aaf945701c #7963 con el congelador intentando agarrar el rwsem: tarea:fsfreeze estado:D pila:0 pid:7364 tgid:7364 ppid:995 Rastreo de llamadas: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 anybody_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Solucione esto haciendo que el lado io_uring respete IOCB_NOWAIT y solo intente una captura de bloqueo del superbloque rwsem si no está configurado. Para un problema normal donde IOCB_NOWAIT siempre estaría configurado, esto devuelve -EAGAIN que hará que el núcleo io_uring emita un intento de bloqueo de la escritura. Eso, a su vez, también hará que se ejecuten las finalizaciones, lo que garantiza el progreso hacia adelante. Dado que el congelamiento requiere CAP_SYS_ADMIN en primer lugar, esto no es algo que pueda ser activado por un usuario normal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: fix 6 GHz scan construction Si existen más de 255 APs coubicados para el conjunto de todos los APs encontrados durante el escaneo de 2.4/5 GHz, entonces la construcción del escaneo de 6 GHz se repetirá eternamente ya que la variable de bucle tiene tipo u8, que nunca puede alcanzar el número encontrado cuando es mayor a 255, y se almacena en una variable u32. También muévalo a los bucles para tener un alcance menor. Usar un u32 está bien, limitamos el número de APs en la lista de escaneo y cada uno tiene un límite en el número de entradas RNR debido al tamaño del marco. Con un límite de 1000 resultados de escaneo, un límite superior de tamaño de marco de 4096 (realmente es más como ~2300) y un tamaño de entrada TBTT de al menos 11, obtenemos un límite superior para el número de ~372k, bien en los límites de un u32.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Se corrige la posible desreferenciación NULL en mtk_crtc_destroy() En mtk_crtc_create(), si la llamada a mbox_request_channel() falla, establecemos el puntero "mtk_crtc->cmdq_client.chan" en NULL. En esa situación, no llamamos a cmdq_pkt_create(). Durante la limpieza, debemos verificar si "mtk_crtc->cmdq_client.chan" es NULL primero antes de llamar a cmdq_pkt_destroy(). Llamar a cmdq_pkt_destroy() es innecesario si no llamamos a cmdq_pkt_create() y dará como resultado una desreferenciación del puntero NULL.