Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/port: Corregir use-after-free, permitir el apagado del decodificador fuera de orden. En apoyo a la investigación de un informe de falla de inicialización [1], cxl_test se actualizó para registrar dispositivos de memoria simulados después de que se hubiera registrado el dispositivo de puerto raíz/bus simulado. Esto provocó que cxl_test se bloqueara con un error de use-after-free con la siguiente firma: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 para mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 restablecer 2) mock_decoder_reset: cxl_port port3: decoder3.0: restablecimiento fuera de servicio, se esperaba decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Vaya: error de protección general, probablemente para dirección no canónica 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Rastreo de llamada: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] En 1) se ha establecido una región con 2 decodificadores de endpoint (7.0 y 14.0). Esos endpoints comparten un decodificador de conmutación común en la topología (3.0). En el desmontaje, 2), decoder14.0 es el primero en ser eliminado y llega al "caso de reinicio fuera de orden" en el decodificador de conmutación. El efecto, sin embargo, es que la limpieza de la región 3 se aborta dejándola intacta y haciendo referencia a decoder14.0. En 3), el segundo intento de desmontaje de la región 3 tropieza con el objeto decoder14.0 obsoleto que ha sido eliminado hace mucho tiempo. La solución aquí es reconocer que la especificación CXL no impone ningún mandato sobre el apagado en orden de los decodificadores de conmutación, el controlador impone la asignación en orden y el hardware impone el commit en orden. Por lo tanto, en lugar de fallar y dejar objetos colgando, siempre elimínelos. Para respaldar que cxl_region_decode_reset() siempre tenga éxito, los fallos de cxl_region_invalidate_memregion() se convierten en advertencias. Allí está bien hacer que el núcleo se bloquee, ya que la integridad del sistema está en riesgo si las cachés no se pueden administrar en torno a eventos de mutación de direcciones físicas como la destrucción de la región CXL. Se agrega un nuevo device_for_each_child_reverse_from() para limpiar port->commit_end después de que se hayan deshabilitado todos los decodificadores dependientes. En otras palabras, si se asignan decodificadores 0->1->2 y se deshabilitan 1->2->0, entonces port->commit_end solo disminuye desde 2 después de que se haya deshabilitado 2, y disminuye hasta cero ya que 1 se deshabilitó previamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thunderbolt: Se corrige la lectura fuera de los límites de pila informada por KASAN en tb_retimer_scan() KASAN informó el siguiente problema: ERROR: KASAN: pila fuera de los límites en tb_retimer_scan+0xffe/0x1550 [thunderbolt] Lectura de tamaño 4 en la dirección ffff88810111fc1c por la tarea kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: GU 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Rastreo de llamadas: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 Esto sucede porque la variable de bucle todavía se incrementa en uno, por lo que max se convierte en 3 en lugar de 2, y esto hace que el segundo bucle lea más allá de la matriz declarada en la pila. Solucione este problema asignando a max directamente en el cuerpo del bucle.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: shmem: corrección de data-race en shmem_getattr() Obtuve el siguiente informe de KCSAN durante las pruebas de syzbot: ====================================================================== ERROR: KCSAN: data-race en generic_fillattr / inode_set_ctime_current escritura en 0xffff888102eb3260 de 4 bytes por la tarea 6565 en la CPU 1: inode_set_ctime_to_ts include/linux/fs.h:1638 [en línea] inode_set_ctime_current+0x169/0x1d0 fs/inode.c:2626 shmem_mknod+0x117/0x180 mm/shmem.c:3443 shmem_create+0x34/0x40 mm/shmem.c:3497 lookup_open fs/namei.c:3578 [en línea] open_last_lookups fs/namei.c:3647 [en línea] path_openat+0xdbc/0x1f00 fs/namei.c:3883 do_filp_open+0xf7/0x200 fs/namei.c:3913 do_sys_openat2+0xab/0x120 fs/open.c:1416 do_sys_open fs/open.c:1431 [en línea] __do_sys_openat fs/open.c:1447 [en línea] __se_sys_openat fs/open.c:1442 [en línea] __x64_sys_openat+0xf3/0x120 fs/open.c:1442 x64_sys_call+0x1025/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:258 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e leído hasta 0xffff888102eb3260 de 4 bytes por la tarea 3498 en la CPU 0: inode_get_ctime_nsec include/linux/fs.h:1623 [en línea] inode_get_ctime include/linux/fs.h:1629 [en línea] generic_fillattr+0x1dd/0x2f0 fs/stat.c:62 shmem_getattr+0x17b/0x200 mm/shmem.c:1157 vfs_getattr_nosec fs/stat.c:166 [en línea] vfs_getattr+0x19b/0x1e0 fs/stat.c:207 vfs_statx_path fs/stat.c:251 [en línea] vfs_statx+0x134/0x2f0 fs/stat.c:315 vfs_fstatat+0xec/0x110 fs/stat.c:341 __do_sys_newfstatat fs/stat.c:505 [en línea] __se_sys_newfstatat+0x58/0x260 fs/stat.c:499 __x64_sys_newfstatat+0x55/0x70 fs/stat.c:499 x64_sys_call+0x141f/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:263 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e valor cambiado: 0x2755ae53 -> 0x27ee44d3 Reportado por Kernel Concurrency Sanitizer en: CPU: 0 UID: 0 PID: 3498 Comm: udevd No contaminado 6.11.0-rc6-syzkaller-00326-gd1f2d51b711a-dirty #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 ======================================================================== Al llamar a generic_fillattr(), si no mantiene el bloqueo de lectura, se producirá una ejecución de datos en las variables miembro del inodo, lo que puede provocar un comportamiento inesperado. Dado que no existe una protección especial cuando shmem_getattr() llama a generic_fillattr(), la ejecución de datos se produce mediante funciones como shmem_unlink() o shmem_mknod(). Esto puede provocar resultados inesperados, por lo que comentarlo no es suficiente. Por lo tanto, al llamar a generic_fillattr() desde shmem_getattr(), es adecuado proteger el inodo utilizando inode_lock_shared() e inode_unlock_shared() para evitar la ejecución de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: arregla un potencial bloqueo con enlaces simbólicos recién creados Syzbot informó que page_symlink(), llamado por nilfs_symlink(), activa la recuperación de memoria que involucra la capa del sistema de archivos, lo que puede resultar en dependencias de bloqueo circular entre el semáforo de lectura/escritura nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) y el pseudobloqueo fs_reclaim. Esto se debe a que después de el commit 21fc61c73c39 ("no poner cuerpos de enlaces simbólicos en pagecache en highmem"), las banderas gfp de la caché de páginas para enlaces simbólicos se sobrescriben a GFP_KERNEL a través de inode_nohighmem(). Esto no es un problema para los enlaces simbólicos leídos desde el dispositivo de respaldo, porque la bandera __GFP_FS se descarta después de que se llama a inode_nohighmem(). Sin embargo, cuando se crea un nuevo enlace simbólico con nilfs_symlink(), los indicadores gfp permanecen sobrescritos en GFP_KERNEL. Luego, la asignación de memoria llamada desde page_symlink(), etc., activa la recuperación de memoria, incluida la capa FS, que puede llamar a nilfs_evict_inode() o nilfs_dirty_inode(). Y estos pueden causar un bloqueo si se los llama mientras se mantiene nilfs->ns_segctor_sem: solucione este problema eliminando el indicador __GFP_FS de los indicadores GFP de la caché de páginas de los enlaces simbólicos recién creados de la misma manera que lo hacen nilfs_new_inode() y __nilfs_read_inode(), como workaround hasta que adoptemos el alcance de asignación de nofs de manera consistente o mejoremos las restricciones de bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: se corrige un error del kernel debido a la falta de limpieza del indicador marcado Syzbot informó que en las operaciones de directorio después de que nilfs2 detecta corrupción del sistema de archivos y se degrada a solo lectura, __block_write_begin_int(), que se llama para preparar escrituras en bloque, puede fallar la verificación BUG_ON para accesos que excedan el tamaño de folio/página, lo que desencadena un error del kernel. Se descubrió que esto se debía a que el indicador "marcado" de una página/folio no se borraba cuando era descartado por la propia rutina de nilfs2, lo que hace que se omita la verificación de cordura de las entradas del directorio cuando se vuelve a cargar la página/folio del directorio. Entonces, arreglen eso. Esto era necesario cuando el uso de la propia rutina de descarte de página de nilfs2 se aplicaba a más que solo archivos de metadatos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el use-after-free del archivo del dispositivo de bloque en __btrfs_free_extra_devids(). Montar btrfs desde dos imágenes (que tienen el mismo fsid y dos dev_uuids diferentes) en cierto orden de ejecución puede activar un UAF para la variable 'device->bdev_file' en __btrfs_free_extra_devids(). Y a continuación se muestran los detalles: 1. Adjunte image_1 a loop0, adjunte image_2 a loop1 y escanee los dispositivos btrfs con ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \ btrfs_device_2 ? loop1 2. monte /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file se libera btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file no está asignado, // lo que apunta a un área de memoria liberada btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF! Arréglelo configurando 'device->bdev_file' como 'NULL' después de cerrar btrfs_device en btrfs_close_one_device().

Motivo del rechazo: esta ID CVE ha sido rechazada o retirada por su autoridad de numeración CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fork: no invocar uffd en fork si ocurre un error Serie de parches "fork: no exponer mm incompleto en fork". Durante fork podemos colocar el espacio de direcciones de memoria virtual en un estado inconsistente antes de que se complete la operación de fork. Además, podemos encontrar un error durante la operación de fork que indique que el espacio de direcciones de memoria virtual está invalidado. Como resultado, no deberíamos exponerlo de ninguna manera a maquinaria externa que pueda interactuar con mm o VMAs, maquinaria que no está diseñada para lidiar con estado incompleto. Actualizamos específicamente la lógica de fork para diferir khugepaged y ksm hasta el final de la operación y solo para ser invocados si no surgió ningún error, y no permitimos que uffd observe eventos de fork si se ha producido un error. Este parche (de 2): Actualmente en fork exponemos el espacio de direcciones virtuales de un proceso al espacio de usuario incondicionalmente si uffd está registrado en VMAs, independientemente de si surgió un error en la bifurcación. Esto se realiza en dup_userfaultfd_complete(), que se invoca de manera incondicional y realiza dos tareas: invocar controladores registrados para el evento UFFD_EVENT_FORK a través de dup_fctx() y limpiar los objetos userfaultfd_fork_ctx establecidos en dup_userfaultfd(). Esto es problemático, porque el espacio de direcciones virtuales puede no estar inicializado correctamente si surge un error. El cambio en el commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") hace que esto sea más pertinente, ya que podemos estar en un estado en el que las entradas en el árbol de maple aún no sean consistentes. Abordamos esto, en caso de error de fork, asegurándonos de revertir el estado que de otra manera esperaríamos limpiar a través del evento que está siendo manejado por el espacio de usuario y realizar la tarea de liberación de memoria que de otra manera realizaría dup_userfaultfd_complete(). Para ello, implementamos una nueva función, dup_userfaultfd_fail(), que realiza el mismo bucle, pero disminuyendo el recuento de referencias. Tenga en cuenta que ejecutamos mmgrab() en los mm principales y secundarios, sin embargo, userfaultfd_ctx_put() ejecutará mmdrop() una vez que el recuento de referencias baje a cero, por lo que evitaremos fugas de memoria correctamente aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Vangogh: Se corrige la escritura fuera de los límites en la memoria del kernel KASAN informa que la tabla de métricas de GPU asignada en vangogh_tables_init() no es lo suficientemente grande para el conjunto de memoria realizado en smu_cmn_init_soft_gpu_metrics(). A continuación se muestra el informe condensado: [33.861314] ERROR: KASAN: slab-out-of-limits en smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [33.861799] Escritura de tamaño 168 en la dirección ffff888129f59500 por la tarea mangoapp/1067 ... [33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Contaminado: GW 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [33.861816] Contaminado: [W]=WARN [ 33.861818] Nombre del hardware: Valve Galileo/Galileo, BIOS F7G0107 01/12/2023 [ 33.861822] Seguimiento de llamadas: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Asignado por la tarea 378 en la CPU 7 a los 22.794876 s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empíricamente podemos confirmar que el primero asigna 152 bytes para la tabla, mientras que el segundo asigna el bloque grande de 168 bytes. La causa raíz parece ser que cuando se agregaron las tablas de métricas de GPU para las partes v2_4, no se consideró agrandar la tabla para que se ajuste. La solución en este parche es más bien "fuerza bruta" y quizás más adelante se debería hacer de una manera más inteligente, extrayendo y consolidando la lógica de tamaño de la versión de la parte en un ayudante común, en lugar de forzar la asignación más grande posible. Sin embargo, por ahora esto funciona y corrige la escritura fuera de los límites. v2: * Se elimina el caso imposible de v3_0. (Mario) (seleccionado de el commit 0880f58f9609f0200483a49429af0f050d281703)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iov_iter: se corrige copy_page_from_iter_atomic() si KMAP_LOCAL_FORCE_MAP generic/077 en x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y con highmem, en huge=always tmpfs, emite una advertencia y luego se cuelga (de manera interrumpida): ADVERTENCIA: CPU: 5 PID: 3517 en mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp No contaminado 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Arregla copy_page_from_iter_atomic() limitándolo en ese caso (include/linux/skbuff.h skb_frag_must_loop() hace algo similar). Pero, en el futuro, ¿quizás CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP sea demasiado sorprendente, haya dejado de ser útil y simplemente deba eliminarse?

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/numa: Se corrige la posible desreferencia de puntero nulo en task_numa_work(). Al ejecutar la prueba stress-ng-vm-segv, encontramos un error de desreferencia de puntero nulo en task_numa_work(). Aquí está el backtrace: [323676.066985] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9: ffff8000800f4ba4 [323676.067145] x8: ffff000810375000 x7: ffff8000ada73974 x6: 0000000000000001 [323676.067147] x5: 0068000b33e26707 x4: 0000000000000001 x3: ffff0009f7158000 [323676.067149] x2: 0000000000000041 x1: 00000000000004400 x0 : 0000000000000000 [323676.067152] Seguimiento de llamadas: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Código: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: deteniendo las CPU secundarias [323676.070184] Iniciando el kernel de volcado de memoria... stress-ng-vm-segv en stress-ng se utiliza para realizar pruebas de estrés a la función de manejo de errores SIGSEGV del sistema, que intenta causar un error SIGSEGV al regresar de anular la asignación de todo el espacio de direcciones del proceso secundario. Normalmente, este programa no causará fallas del kernel. Pero antes de que la llamada al sistema munmap vuelva al modo de usuario, se podría agregar y ejecutar una posible task_numa_work() para el equilibrio de NUMA. En este escenario, dado que el proceso secundario no tiene ningún vma después de munmap, vma_next() en task_numa_work() devolverá un puntero nulo incluso si el iterador vma se reinicia desde 0. Vuelva a verificar el puntero vma antes de desreferenciarlo en task_numa_work().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: spi-fsl-dspi: Se corrige el bloqueo cuando no se utiliza la selección de chip GPIO. Se agrega una verificación para el valor de retorno de spi_get_csgpiod() para evitar pasar un puntero NULL a gpiod_direction_output(), lo que evita un bloqueo cuando no se utiliza la selección de chip GPIO. Corrección del siguiente fallo: [4.251960] No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 [4.260762] Información de cancelación de memoria: [4.263556] ESR = 0x0000000096000004 [4.267308] EC = 0x25: DABT (EL actual), IL = 32 bits [4.272624] SET = 0, FnV = 0 [4.275681] EA = 0, S1PTW = 0 [4.278822] FSC = 0x04: error de traducción de nivel 0 [4.283704] Información de cancelación de datos: [4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [000000000000000] dirección de usuario pero active_mm es swapper [ 4.308805] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Módulos vinculados en: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Nombre del hardware: Placa QDS LS1046A (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 00000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9: 0000000000000008 [ 4.402502] x8: 00000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 00000000000000200 x4 : 00000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Rastreo de llamadas: [ 4.426362] dirección_salida_gpiod+0x34/0x5c (P) [ 4.431067] dirección_salida_gpiod+0x18/0x5c (L) [ 4.435771] configuración_dspi+0x220/0x334