Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab: se corrige la advertencia causada por la creación duplicada de kmem_cache en kmem_buckets_create. el commit b035f5a6d852 ("mm: slab: reduce la alineación mínima de kmalloc() si es posible el rebote de DMA") redujo ARCH_KMALLOC_MINALIGN a 8 en arm64. Sin embargo, con KASAN_HW_TAGS habilitado, arch_slab_minalign() se convierte en 16. Esto hace que kmalloc_caches[*][8] se asocie a kmalloc_caches[*][16], lo que hace que kmem_buckets_create() intente crear un kmem_cache para el tamaño 16 dos veces. Esta duplicación activa advertencias en el arranque: [ 2.325108] ------------[ cortar aquí ]------------ [ 2.325135] kmem_cache con el nombre 'memdup_user-16' ya existe [ 2.325783] ADVERTENCIA: CPU: 0 PID: 1 en mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Módulos vinculados en: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Nombre del hardware: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 00000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 205b x10: 2d2d2d2d2d2d2d2d x9 : 00000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 00000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Rastreo de llamadas: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ fin de seguimiento 000000000000000 ]--- [ 2.403704] ------------[ cortar aquí ]------------ [ 2.404716] kmem_cache del nombre 'msg_msg-16' ya existe [ 2.404801] ADVERTENCIA: CPU: 2 PID: 1 en mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Módulos vinculados en: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Contaminado: GW 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Contaminado: [W]=WARN [ 2.405043] Nombre del hardware: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Rastreo de llamada: [ 2 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Iniciar el trabajo de actualización de RTC más tarde El trabajo de actualización de RTC implica que el tiempo de ejecución reanude el controlador UFS. Por lo tanto, solo inicie el trabajo de actualización de RTC después de que se haya inicializado por completo la administración de energía en tiempo de ejecución en el controlador UFS. Este parche corrige el siguiente fallo del kernel: Error interno: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: eventos ufshcd_rtc_work Seguimiento de llamadas: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: Arreglar slab-use-after-free en scmi_bus_notifier() El scmi_dev->name se libera prematuramente en __scmi_device_destroy(), lo que provoca slab-use-after-free al acceder a scmi_dev->name en scmi_bus_notifier(). Por lo tanto, mueva la liberación de scmi_dev->name a scmi_device_release() para evitar slab-use-after-free. | ERROR: KASAN: slab-use-after-free en strncmp+0xe4/0xec | Lectura de tamaño 1 en la dirección ffffff80a482bcc0 por la tarea swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 No contaminado 6.6.38-debug #1 | Nombre del hardware: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Rastreo de llamadas: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | dispositivo_anular_registro+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | plataforma_probe+0xc4/0x19c | realmente_probe+0x32c/0x99c | __controlador_dispositivo_sondeo+0x15c/0x3c4 | controlador_dispositivo_sondeo+0x5c/0x170 | __controlador_adjunto+0x1c8/0x440 | bus_para_cada_dispositivo+0xf4/0x178 | controlador_adjunto+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Asignado por la tarea 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | es: __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_para_cada_dispositivo+0xf4/0x178 | controlador_adjuntar+0x3c/0x58 | bus_agregar_controlador+0x234/0x4d4 | registro_controlador+0xf4/0x3c0 | __registro_controlador_plataforma+0x60/0x88 | scmi_driver_init+0xb0/0x104 | hacer_una_llamada_iniciativa+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_de_la_bifurcación+0x10/0x20 | | Liberado por la tarea 1: | kasan_guardar_pila+0x2c/0x54 | kasan_establecer_pista+0x2c/0x40 | es: kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | plataforma_probe+0xc4/0x19c | realmente_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | dispositivo_de_sonda_del_controlador+0x5c/0x170 | __adjuntar_controlador+0x1c8/0x440 | bus_para_cada_dispositivo+0xf4/0x178 | adjuntar_controlador+0x3c/0x58 | agregar_controlador_del_bus+0x234/0x4d4 | registro_del_controlador+0xf4/0x3c0 | __registro_del_controlador_de_plataforma+0x60/0x88 | inicialización_del_controlador_scmi+0xb0/0x104 | hacer_una_llamada_de_inicio+0xb4/0x664 | inicialización_del_kernel_freeable+0x3c8/0x894 | inicialización_del_kernel+0x24/0x1e8 | retirar_de_la_bifurcación+0x10/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: qcom: scm: se corrige una desreferencia de puntero NULL. Algunas llamadas SCM se pueden invocar con __scm siendo NULL (es posible que no se haya investigado el controlador y no se investigará ya que no hay ninguna entrada SCM en el árbol de dispositivos). Asegúrese de que no desreferenciamos un puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panthor: Sea más estricto con las banderas de mapeo de IO La implementación actual de panthor_device_mmap_io() tiene dos problemas: 1. Para mapear DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() abandona si VM_WRITE está configurado, pero no borra VM_MAYWRITE. Eso significa que el espacio de usuario puede usar mprotect() para hacer que el mapeo sea escribible más tarde. Este es un problema clásico del controlador de Linux. No creo que esto realmente tenga algún impacto en la práctica: cuando la GPU está encendida, las escrituras en FLUSH_ID parecen ignorarse; y cuando la GPU no está encendida, la página dummy_latest_flush proporcionada por el controlador está diseñada deliberadamente para no hacer ningún vaciado, por lo que lo único que escribir en dummy_latest_flush podría lograr sería hacer que ocurrieran *más* vaciados. 2. panthor_device_mmap_io() no bloquea las asignaciones MAP_PRIVATE (que son asignaciones sin el indicador VM_SHARED). MAP_PRIVATE en combinación con VM_MAYWRITE indica que la VMA tiene semántica de copia en escritura, que para VM_PFNMAP son semicompatibles pero con bastante mala calidad. En particular, en una asignación de este tipo, el controlador solo puede instalar PTE durante mmap() llamando a remap_pfn_range() (porque remap_pfn_range() quiere **almacenar la dirección física de la memoria física asignada en el vm_pgoff de la VMA**); la instalación de PTE más tarde con un controlador de errores (como lo hace panthor) no se admite en asignaciones privadas y, por lo tanto, si intenta generar un error en una asignación de este tipo, vmf_insert_pfn_prot() se bloquea cuando llega a una comprobación de ERROR(). Arréglelo borrando la marca VM_MAYWRITE (la escritura en el espacio de usuario en FLUSH_ID no tiene sentido) y requiriendo VM_SHARED (la semántica de copia en escritura para FLUSH_ID no tiene sentido). Los reproductores para ambos escenarios están en las notas de mi parche en la lista de correo; probé que estos errores existen en una máquina Rock 5B. Tenga en cuenta que solo probé la compilación del parche, no lo he probado; aún no tengo una configuración de compilación de kernel que funcione para la máquina de prueba. Pruébelo antes de aplicarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: Nunca decremente pending_async_copies en caso de error El flujo de error en nfsd4_copy() llama a cleanup_async_copy(), que ya decrementa nn->pending_async_copies.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: dvbdev: evitar el riesgo de acceso fuera de memoria El dvbdev contiene una variable estática utilizada para almacenar dvb minors. El comportamiento de la misma depende de si CONFIG_DVB_DYNAMIC_MINORS está configurado o no. Cuando no está configurado, dvb_register_device() no comprobará los límites, ya que dependerá de que una llamada anterior a dvb_register_adapter() ya lo estaría aplicando. De forma similar, dvb_device_open() utiliza la suposición de que las funciones de registro ya realizaron las comprobaciones necesarias. Esto puede ser frágil si algún dispositivo termina utilizando llamadas diferentes. Esto también genera advertencias en los analizadores de comprobaciones estáticas como Coverity. Por lo tanto, agregue protecciones explícitas para evitar el riesgo potencial de problemas de OOM.

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.