Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: gpib: Fix cb7210 pcmcia Oops. La estructura pcmcia_driver seguía usando únicamente la inicialización anterior de .name en el campo drv. Esto provocaba un puntero nulo deref Oops en strcmp llamado desde pcmcia_register_driver. Inicialice el campo name de la estructura pcmcia_driver.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: objtool, nvmet: Se corrige el acceso a la pila fuera de los límites en nvmet_ctrl_state_show(). La matriz csts_state_names[] solo tiene seis entradas dispersas, pero el código de iteración en nvmet_ctrl_state_show() itera siete, lo que resulta en una posible lectura de la pila fuera de los límites. Se soluciona. Se corrige la siguiente advertencia con un kernel UBSAN: vmlinux.o: advertencia: objtool: .text.nvmet_ctrl_state_show: final inesperado de sección.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: simple-card-utils: No usar __free(device_node) en el commit 419d1918105e de graph_util_parse_dai() ("ASoC: simple-card-utils: usar __free(device_node) para el nodo de dispositivo") usa __free(device_node) para dlc->of_node, pero es necesario mantenerlo mientras se usa el controlador. No usar __free(device_node) en graph_util_parse_dai().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mce: usar is_copy_from_user() para determinar el contexto de copia del usuario. Serie de parches "mm/hwpoison: Corregir regresiones en la gestión de fallos de memoria", v4. ## 1. ¿Qué intento hacer?: Este conjunto de parches resuelve dos regresiones críticas relacionadas con la gestión de fallos de memoria que han aparecido en el kernel original desde la versión 5.17, en comparación con la 5.10 LTS. - caso de copyin: se encontró un error en la página de usuario mientras el kernel copiaba desde el espacio de usuario. - caso de instr: se encontró un error al obtener instrucciones en el espacio de usuario. ## 2. ¿Cuál es el resultado esperado y por qué? - Para el caso de copyin: el kernel puede recuperarse del error encontrado donde el kernel ejecuta get_user() o copy_from_user() si en esos lugares se obtiene un error y el kernel devuelve -EFAULT al proceso en lugar de bloquearse. Más específicamente, el controlador de MCE comprueba el tipo de controlador de corrección para decidir si se puede recuperar un #MC en el kernel. Cuando se encuentra EX_TYPE_UACCESS, el PC salta al código de recuperación especificado en _ASM_EXTABLE_FAULT() y devuelve un -EFAULT al espacio de usuario. - En el caso de instr: Si se encuentra un error durante la obtención de instrucciones en el espacio de usuario, es posible una recuperación completa. El proceso de usuario toma #PF, Linux asigna una nueva página y la completa leyendo del almacenamiento. ## 3. Qué sucede realmente y por qué - En el caso de copyin: Pánico del kernel desde la v5.17. El commit 4c132d1d844a ("x86/futex: Eliminar el uso de .fixup") introdujo un nuevo tipo de corrección extable, EX_TYPE_EFAULT_REG, y parches posteriores actualizaron el tipo de corrección extable para operaciones de copia desde el usuario, cambiándolo de EX_TYPE_UACCESS a EX_TYPE_EFAULT_REG. Esto interrumpe la gestión previo de EX_TYPE_UACCESS cuando se encuentra error en get_user() o copy_from_user(). - Para el caso instr: el proceso del usuario es eliminado por una señal SIGBUS debido a la ejecución #CMCI y #MCE Cuando se consume un error de memoria sin corregir, hay una ejecución entre el CMCI del controlador de memoria que informa un error sin corregir con una firma UCNA y el informe del núcleo y la comprobación de la máquina con firma SRAR cuando los datos están a punto de consumirse. ### Antecedentes: por qué los errores *UN*corregidos están vinculados a *C*MCI en la plataforma Intel [1] Antes de Icelake, los controladores de memoria informaban de eventos de depuración de patrullaje que detectaban un error sin corregir no visto previamente en la memoria mediante la señalización de una comprobación de la máquina de difusión con una firma SRAO (Acción recuperable de software opcional) en el banco de comprobación de la máquina. Esto era excesivo porque no es un problema urgente que ningún núcleo esté a punto de consumir esos datos erróneos. También se ha descubierto que varias UCE SRAO pueden causar interrupciones MCE anidadas y, finalmente, convertirse en una IERR. Por lo tanto, Intel degrada la firma del banco de verificación de la máquina de la limpieza de patrullaje de SRAO a UCNA (sin corregir, no se requiere acción) y la señal cambia a #CMCI. Para aumentar la confusión, Linux realiza una acción (en uc_decode_notifier()) para intentar desconectar la página a pesar del nombre de la firma UC*NA*. ### Antecedentes: ¿por qué #CMCI y #MCE compiten cuando el veneno consume datos en la plataforma Intel? [1] Tras decidir que CMCI/UCNA es la mejor acción para los errores de limpieza de patrullaje, el controlador de memoria también la utiliza para las lecturas. Sin embargo, el controlador de memoria se ejecuta de forma asíncrona desde el núcleo y no puede distinguir entre una lectura "real" y una lectura especulativa. Por lo tanto, ejecutará CMCI/UCNA si se encuentra un error en cualquier lectura. Por lo tanto: 1) El núcleo es inteligente y cree que ----truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: objtool, spi: amd: Se corrige el acceso a la pila fuera de los límites en amd_set_spi_freq(). Si speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() itera sobre toda la matriz amd_spi_freq sin interrumpir la ejecución antes de tiempo, lo que provoca que 'i' supere los límites de la matriz. Para solucionar esto, se detiene el bucle al llegar a la última entrada, de modo que el valor bajo de speed_hz se limite a AMD_SPI_MIN_HZ. Se corrige la siguiente advertencia con un kernel UBSAN: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falla a la siguiente función amd_spi_set_opcode().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: Agregar comprobación de los límites de matriz en veml6075_read_int_time_ms La matriz contiene solo 5 elementos, pero el índice calculado por veml6075_read_int_time_index puede variar de 0 a 7, lo que podría provocar un acceso fuera de los límites. La comprobación evita este problema. Coverity Issue CID 1574309: (#1 de 1): Lectura fuera de los límites (OVERRUN) overrun-local: Desbordamiento de la matriz veml6075_it_ms de 5 elementos de 4 bytes en el índice de elemento 7 (desplazamiento de byte 31) utilizando el índice int_index (que evalúa a 7) Esto es endurecimiento contra hardware potencialmente dañado. Es bueno tenerlo, pero no es necesario retroportarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/raid10: esperar la barrera antes de devolver una solicitud de descarte con REQ_NOWAIT. raid10_handle_discard debe esperar la barrera antes de devolver una bio de descarte con REQ_NOWAIT. No es necesario imprimir un seguimiento de llamadas de advertencia si una bio de descarte tiene la bandera REQ_NOWAIT. El ingeniero de calidad suele revisar dmesg e informa de un error si dmesg tiene un seguimiento de llamadas de advertencia/error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: rechaza inodos en disco de un tipo no compatible Syzbot ha informado del siguiente ERROR: ¡ERROR del kernel en fs/inode.c:668! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit No contaminado 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clear_inode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Esto ocurre cuando 'clear_inode()' intenta finalizar un inodo JFS subyacente de tipo desconocido. Según la descripción del diseño JFS de https://jfs.sourceforge.net/project/pub/jfslayout.pdf, los tipos de inodo del 5 al 15 están reservados para futuras extensiones y no deberían encontrarse en un sistema de archivos válido. Por lo tanto, añada una comprobación adicional para el tipo de inodo válido en 'copy_from_dinode()'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/resctrl: Se corrige la asignación del CLOSID más limpio en plataformas sin monitores. El commit 6eac36bb9eb0 ("x86/resctrl: Asignar el CLOSID más limpio buscando closid_num_dirty_rmid") añadió lógica que hace que resctrl busque el CLOSID con la menor cantidad de líneas de caché sucias al crear un nuevo grupo de control, si así lo solicita el código de la arquitectura. Esto depende de los valores leídos de los contadores llc_occupancy. Esta lógica es aplicable a arquitecturas donde el CLOSID forma parte del identificador de monitorización y, por lo tanto, no permite total libertad para elegir un identificador de monitorización sin usar para un CLOSID determinado. Esta compatibilidad no tuvo en cuenta que algunas plataformas podrían no tener estos contadores. Esto provoca una desreferencia de puntero nulo al crear un nuevo grupo de control, ya que la matriz no fue asignada por dom_data_init(). Como esta función no es necesaria en plataformas que no tienen monitores de ocupación de caché, agregue esto a la verificación que se realiza cuando se asigna un nuevo grupo de control.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Reemplazar Mutex con Spinlock para el acceso a registros RLCG para evitar la inversión de prioridad en SRIOV. El acceso a registros RLCG es una forma de que las funciones virtuales accedan de forma segura a los registros de la GPU en un entorno virtualizado, incluyendo vaciados de TLB y lecturas de registros. Cuando varios subprocesos o VF intentan acceder a los mismos registros simultáneamente, puede provocar condiciones de ejecución. Al usar la interfaz RLCG, el controlador puede serializar el acceso a los registros. Esto significa que solo un subproceso puede acceder a los registros a la vez, lo que evita conflictos y garantiza que las operaciones se realicen correctamente. Además, cuando una tarea de baja prioridad contiene un mutex que necesita una tarea de alta prioridad (es decir, si un subproceso con un spinlock intenta adquirir un mutex), puede provocar una inversión de prioridad. El acceso a registros en amdgpu_virt_rlcg_reg_rw, especialmente en una ruta de código rápida, es crítico. La pila de llamadas muestra que se está llamando a la función amdgpu_virt_rlcg_reg_rw, que intenta adquirir el mutex. Esta función se invoca desde amdgpu_sriov_wreg, que a su vez se llama desde gmc_v11_0_flush_gpu_tlb. El error [ERROR: Contexto de espera no válido] indica que un subproceso intenta adquirir un mutex mientras se encuentra en un contexto que no le permite dormir (como mantener un spinlock). Corrige lo siguiente: [253.013423] ============================== [253.013434] [ERROR: Contexto de espera no válido] [253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Contaminado: G U OE [ 253.013464] ----------------------------- [ 253.013475] kworker/0:1/10 is trying to lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.013815] other info that might help us debug this: [ 253.013827] context-{4:4} [ 253.013835] 3 locks held by kworker/0:1/10: [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680 [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680 [ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024 [ 253.014224] Workqueue: events work_for_cpu_fn [ 253.014241] Call Trace: [ 253.014250] [ 253.014260] dump_stack_lvl+0x9b/0xf0 [ 253.014275] dump_stack+0x10/0x20 [ 253.014287] __lock_acquire+0xa47/0x2810 [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014562] ? __lock_acquire+0xa6b/0x2810 [ 253.014578] __mutex_lock+0x85/0xe20 [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014782] ? sched_clock_noinstr+0x9/0x10 [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014808] ? local_clock_noinstr+0xe/0xc0 [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.015029] mutex_lock_nested+0x1b/0x30 [ 253.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu] [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu] [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu] [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu] [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu] [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu] [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: core: Clear table_sz when rproc_shutdown Existe un caso como el siguiente que podría activar el volcado del kernel: Use U-Boot para iniciar el procesador remoto (rproc) con la tabla de recursos publicada en una dirección fija por rproc. Después de que el kernel se inicie, detenga el rproc, cargue un nuevo firmware que no tenga tabla de recursos e inicie rproc. Al iniciar rproc con un firmware que no tiene tabla de recursos, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` activará el volcado, porque rproc->cache_table se establece en NULL durante la última operación de detención, pero rproc->table_sz sigue siendo válido. Este problema se encuentra en i.MX8MP y i.MX9. Volcado como se muestra a continuación: No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 Información de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: error de traducción de nivel 0 Información de aborto de datos: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 pgtable de usuario: páginas de 4k, VA de 48 bits, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Error interno: Oops: 0000000096000004 [#1] PREEMPT Módulos SMP vinculados: CPU: 2 UID: 0 PID: 1060 Comm: sh No contaminado 6.14.0-rc7-next-20250317-dirty #38 Nombre del hardware: Placa NXP i.MX8MPlus EVK (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : Rastreo de llamadas: __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Rastreo de llamadas: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c almacén de estado+0x40/0x104 almacén de atributos de desarrollo+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invocar_llamada al sistema+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Borre rproc->table_sz para solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mediatek: dp: drm_err => dev_err en la ruta HPD para evitar un puntero nulo. La función mtk_dp_wait_hpd_asserted() puede llamarse antes de asignar el puntero `mtk_dp->drm_dev` en mtk_dp_bridge_attach(). Específicamente, se puede llamar a través de esta ruta de llamada: - mtk_edp_wait_hpd_asserted - [panel probe] - dp_aux_ep_probe El uso de impresiones de nivel "drm" en cualquier parte de esta ruta de llamada provoca una desreferencia del puntero nulo. Cambie el mensaje de error directamente en mtk_dp_wait_hpd_asserted() a dev_err() para evitar esto. Cambie también los mensajes de error en mtk_dp_parse_capabilities(), que es llamado por mtk_dp_wait_hpd_asserted(). Al tocar estas impresiones, agregue también el código de error para facilitar la depuración futura.