Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: Corrige la advertencia de KMSAN en decode_getfattr_attrs() Corrige la siguiente advertencia de KMSAN: CPU: 1 UID: 0 PID: 7651 Comm: cp Contaminado: GB Contaminado: [B]=BAD_PAGE Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009) ====================================================== ============================================================= ERROR: KMSAN: valor no inicializado en decodificar_getfattr_attrs+0x2d6d/0x2f90 decodificar_getfattr_attrs+0x2d6d/0x2f90 decodificar_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 llamar_decodificar+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 La advertencia de KMSAN se activa en decode_getfattr_attrs(), al llamar a decode_attr_mdsthreshold(). Parece que fattr->mdsthreshold no está inicializado. Solucione el problema inicializando fattr->mdsthreshold en NULL en nfs_fattr_init().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: se corrige un error en la suspensión del sistema si el dispositivo ya estaba suspendido en tiempo de ejecución. Si el dispositivo ya estaba suspendido en tiempo de ejecución, durante la suspensión del sistema no podemos acceder a los registros del dispositivo, de lo contrario, se bloqueará. Además, no podemos acceder a ningún registro después de dwc3_core_exit() en algunas plataformas, por lo que movemos la llamada dwc3_enable_susphy() al principio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86/amd/pmc: Detectar cuando STB no está disponible Cargar el módulo amd_pmc como: amd_pmc enable_stb=1 ...puede generar los siguientes mensajes en el búfer de anillo del kernel: amd_pmc AMDI0009:00: Error en el comando SMU. err: 0xff ioremap en RAM en 0x000000000000000 - 0x0000000000ffffff ADVERTENCIA: CPU: 10 PID: 2151 en arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Una depuración adicional revela que esto ocurre cuando las solicitudes de S2D_PHYS_ADDR_LOW y S2D_PHYS_ADDR_HIGH devuelven un valor de 0, lo que indica que el STB es inaccesible. Para evitar la advertencia de ioremap y proporcionar claridad al usuario, controle la dirección no válida y muestre un mensaje de error.

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: 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: 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: 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/i915/hdcp: Agregar comprobación del codificador en intel_hdcp_get_capability A veces, durante el escenario de conexión en caliente o el escenario de suspensión/reanudación, el codificador no siempre se inicializa cuando intel_hdcp_get_capability agrega una comprobación para evitar la desreferencia del puntero nulo del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Se solucionó otro bloqueo durante la actualización de RTC Si ufshcd_rtc_work llama a ufshcd_rpm_put_sync() y el usage_count del pm es 0, ingresaremos a la devolución de llamada de suspensión en tiempo de ejecución. Sin embargo, la devolución de llamada de suspensión en tiempo de ejecución esperará para vaciar ufshcd_rtc_work, lo que provocará un bloqueo. Reemplace ufshcd_rpm_put_sync() con ufshcd_rpm_put() para evitar el bloqueo.

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: 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.

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.