Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: nf_conncount: actualizar last_gc solo cuando se ha realizado la GC<br /> <br /> Actualmente, last_gc se actualiza cada vez que se rastrea una nueva conexión, lo que significa que se actualiza incluso si no se realizó una GC. Con una tasa de paquetes suficientemente alta, es posible eludir siempre la GC, haciendo que la lista crezca infinitamente.<br /> <br /> Actualizar el valor de last_gc solo cuando se ha realizado realmente una GC.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfs: Solución para el desbloqueo temprano de lectura de página con EOF en el medio<br /> <br /> La recopilación de resultados de lectura para lecturas en búfer parece adelantarse a la finalización de las subpeticiones bajo algunas circunstancias, como se puede ver en el siguiente fragmento de registro:<br /> <br /> 9p_client_res: cliente 18446612686390831168 response P9_TREAD tag 0 err 0<br /> ...<br /> netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0<br /> ...<br /> netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2<br /> netfs_folio: i=157f3 ix=00004-00004 read-done<br /> netfs_folio: i=157f3 ix=00004-00004 read-unlock<br /> netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2<br /> netfs_folio: i=157f3 ix=00005-00005 read-done<br /> netfs_folio: i=157f3 ix=00005-00005 read-unlock<br /> ...<br /> netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff<br /> netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c<br /> netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff<br /> netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8<br /> ...<br /> netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0<br /> netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0<br /> <br /> El &amp;#39;cto=5fb2&amp;#39; indica la posición de archivo recopilada a la que hemos recogido resultados hasta ahora, pero aún nos quedan 0x4e bytes más, por lo que no deberíamos haber recopilado el folio ix=00005 todavía. La subpetición &amp;#39;ZERO&amp;#39; que borra la cola ocurre después de que desbloqueamos el folio, permitiendo que la aplicación vea la cola no borrada a través de mmap.<br /> <br /> El problema es que netfs_read_unlock_folios() desbloqueará un folio en el que la cantidad de resultados de lectura recopilados alcanza la posición EOF, pero la subpetición ZERO se encuentra más allá de eso y, por lo tanto, ocurre después.<br /> <br /> Solucione esto cambiando la comprobación de fin para que siempre sea el fin del folio y nunca el fin del archivo.<br /> <br /> En el futuro, debería considerar borrar hasta el final del folio aquí en lugar de añadir una subpetición ZERO para hacer esto. Por otro lado, la subpetición ZERO puede ejecutarse en paralelo con una subpetición READ asíncrona. Además, la subpetición ZERO aún puede ser necesaria para, por ejemplo, manejar extensiones en un archivo ceph que no tienen ningún almacenamiento de respaldo y, por lo tanto, son implícitamente todo ceros.<br /> <br /> Esto se puede reproducir creando un archivo cuyo tamaño no se alinea con un límite de página, por ejemplo, 24998 (0x5fb2) bytes, y luego haciendo algo como:<br /> <br /> xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \<br /> -c "mread -v 0 0x6000" /xfstest.test/x<br /> <br /> Los últimos 0x4e bytes deberían ser todos 00, pero si la cola no ha sido borrada todavía, es posible que vea basura allí. Esto se puede reproducir con kafs modificando el kernel para deshabilitar la llamada a netfs_read_subreq_progress() y para evitar que afs_issue_read() realice la llamada asíncrona para NETFS_READAHEAD. La reproducción se puede facilitar insertando un mdelay(100) en netfs_issue_read() para el caso de la subpetición ZERO.<br /> <br /> AFS y CIFS normalmente no suelen mostrar esto, ya que despachan operaciones READ de forma asíncrona, lo que permite que la subpetición ZERO termine primero. La operación READ de 9P es completamente síncrona, por lo que la subpetición ZERO siempre ocurrirá después. Sin embargo, no se ve todo el tiempo, porque la recopilación puede realizarse en un hilo de trabajo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iommu/sva: invalidar entradas IOTLB obsoletas para el espacio de direcciones del kernel<br /> <br /> Se introduce una nueva interfaz IOMMU para vaciar las entradas de la caché de paginación IOTLB para el espacio de direcciones del kernel de la CPU. Esta interfaz se invoca desde el código de arquitectura x86 que gestiona las tablas de páginas combinadas de usuario y kernel, específicamente antes de que cualquier página de tabla de páginas del kernel sea liberada y reutilizada.<br /> <br /> Esto aborda el problema principal con vfree(), que es una ocurrencia común y puede ser activado por usuarios no privilegiados. Si bien esto resuelve el problema principal, no aborda un caso extremadamente raro relacionado con la desconexión de memoria que estaba presente como memoria reservada en el arranque, que no puede ser activado por usuarios no privilegiados. La discusión se puede encontrar en el enlace a continuación.<br /> <br /> Habilitar SVA en la arquitectura x86 ya que la IOMMU ahora puede recibir notificación para vaciar la caché de paginación antes de liberar las páginas de la tabla de páginas del kernel de la CPU.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> arm64: Establecer __nocfi en swsusp_arch_resume()<br /> <br /> Se informa de un DABT[1] en un sistema basado en Android al reanudar desde la hibernación. Esto ocurre porque swsusp_arch_suspend_exit() está marcado con SYM_CODE_*() y no tiene un hash CFI, pero swsusp_arch_resume() intentará verificar el hash CFI al llamar a una copia de swsusp_arch_suspend_exit().<br /> <br /> Dado que existe un requisito de que el punto de entrada a swsusp_arch_suspend_exit() es el primer byte de la sección .hibernate_exit.text, no podemos solucionar esto marcando swsusp_arch_suspend_exit() con SYM_FUNC_*(). La solución más sencilla por ahora es deshabilitar la verificación CFI en swsusp_arch_resume().<br /> <br /> Marcar swsusp_arch_resume() como __nocfi para deshabilitar la verificación CFI.<br /> <br /> [1]<br /> [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc<br /> [ 22.991934][ T1] Mem abort info:<br /> [ 22.991934][ T1] ESR = 0x0000000096000007<br /> [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 22.991934][ T1] SET = 0, FnV = 0<br /> [ 22.991934][ T1] EA = 0, S1PTW = 0<br /> [ 22.991934][ T1] FSC = 0x07: level 3 translation fault<br /> [ 22.991934][ T1] Data abort info:<br /> [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000<br /> [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper<br /> [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP<br /> [ 22.991934][ T1] Dumping ftrace buffer:<br /> [ 22.991934][ T1] (ftrace buffer empty)<br /> [ 22.991934][ T1] Modules linked in:<br /> [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419<br /> [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT)<br /> [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344<br /> [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344<br /> [ 22.991934][ T1] sp : ffffffc08006b960<br /> [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820<br /> [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000<br /> [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058<br /> [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004<br /> [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000<br /> [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000<br /> [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b<br /> [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530<br /> [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000<br /> [ 22.991934][ T1] Call trace:<br /> [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344<br /> [ 22.991934][ T1] hibernation_restore+0x158/0x18c<br /> [ 22.991934][ T1] load_image_and_restore+0xb0/0xec<br /> [ 22.991934][ T1] software_resume+0xf4/0x19c<br /> [ 22.991934][ T1] software_resume_initcall+0x34/0x78<br /> [ 22.991934][ T1] do_one_initcall+0xe8/0x370<br /> [ 22.991934][ T1] do_initcall_level+0xc8/0x19c<br /> [ 22.991934][ T1] do_initcalls+0x70/0xc0<br /> [ 22.991934][ T1] do_basic_setup+0x1c/0x28<br /> [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148<br /> [ 22.991934][ T1] kernel_init+0x20/0x1a8<br /> [ 22.991934][ T1] ret_from_fork+0x10/0x20<br /> [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)<br /> <br /> [catalin.marinas@arm.com: commit log updated by Mark Rutland]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dpll: Prevenir registros duplicados<br /> <br /> Modificar las funciones auxiliares de registro internas dpll_xa_ref_{dpll,pin}_add() para rechazar intentos de registro duplicados.<br /> <br /> Anteriormente, si un llamador intentaba registrar el mismo pin múltiples veces (con las mismas ops, priv y cookie) en el mismo dispositivo, el núcleo incrementaba silenciosamente el contador de referencias y devolvía éxito. Este comportamiento es incorrecto porque si el llamador realiza estos registros duplicados, entonces para el primero se asigna dpll_pin_registration y para los demás se incrementa el dpll_pin_ref.refcount asociado. Durante la primera anulación de registro se libera el dpll_pin_registration asociado y para los demás se dispara una advertencia.<br /> <br /> Esto se soluciona actualizando la lógica para devolver -EEXIST si se encuentra un registro coincidente, para aplicar una política estricta de &amp;#39;registrar una vez&amp;#39;.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> wifi: ath12k: solucionar interbloqueo al vaciar tramas de gestión<br /> <br /> El commit [1] convirtió el elemento de trabajo de transmisión de gestión en un trabajo wiphy. Dado que un trabajo wiphy solo puede ejecutarse bajo la protección del bloqueo wiphy, ocurre una condición de carrera en el siguiente escenario:<br /> <br /> 1. una trama de gestión se pone en cola para transmisión.<br /> 2. se llama a ath12k_mac_op_flush() para vaciar las tramas pendientes asociadas con el hardware (es decir, vif es NULL). Luego, en ath12k_mac_flush(), el proceso espera a que la transmisión finalice.<br /> 3. Dado que el bloqueo wiphy ha sido tomado por el proceso de vaciado, el elemento de trabajo de transmisión no tiene oportunidad de ejecutarse, de ahí el interbloqueo.<br /> <br /> Desde la perspectiva del usuario, este interbloqueo resulta en el siguiente problema:<br /> <br /> wlp8s0: autenticar con xxxxxx (dirección local=xxxxxx)<br /> wlp8s0: enviar autenticación a xxxxxx (intento 1/3)<br /> wlp8s0: autenticar con xxxxxx (dirección local=xxxxxx)<br /> wlp8s0: enviar autenticación a xxxxxx (intento 1/3)<br /> wlp8s0: autenticado<br /> wlp8s0: asociar con xxxxxx (intento 1/3)<br /> wlp8s0: abortando asociación con xxxxxx por elección local (Razón: 3=DEAUTH_LEAVING)<br /> ath12k_pci 0000:08:00.0: falló al vaciar la cola de transmisión de gestión, paquetes de gestión pendientes 1<br /> <br /> El interbloqueo puede evitarse invocando wiphy_work_flush() para ejecutar proactivamente el elemento de trabajo en cola. Nótese que en realidad ya está presente en ath12k_mac_op_flush(), sin embargo, no protege el caso en que vif es NULL. Por lo tanto, se mueve hacia adelante para cubrir también este caso.<br /> <br /> Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> platform/x86: hp-bioscfg: Corrección de advertencias de kobject para nombres de atributos vacíos<br /> <br /> El controlador hp-bioscfg intenta registrar kobjects con nombres vacíos cuando la BIOS de HP devuelve atributos con cadenas de nombre vacías. Esto causa múltiples advertencias del kernel:<br /> <br /> kobject: (00000000135fb5e6): ¡se intentó registrar con nombre vacío!<br /> WARNING: CPU: 14 PID: 3336 en lib/kobject.c:219 kobject_add_internal+0x2eb/0x310<br /> <br /> Añadir validación en hp_init_bios_buffer_attribute() para verificar si el nombre del atributo está vacío después de analizarlo desde el búfer WMI. Si está vacío, registrar un mensaje de depuración y omitir el registro de ese atributo, permitiendo que el módulo continúe procesando otros atributos válidos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bonding: proporcionar un puntero de red a __skb_flow_dissect()<br /> <br /> Después de 3cbf4ffba5ee (&amp;#39;net: integrar el espacio de nombres de red en __skb_flow_dissect&amp;#39;)<br /> tenemos que proporcionar un puntero de red a __skb_flow_dissect(),<br /> ya sea a través de skb-&amp;gt;dev, skb-&amp;gt;sk, o un puntero proporcionado por el usuario.<br /> <br /> En el siguiente caso, syzbot pudo &amp;#39;cocinar&amp;#39; un skb básico.<br /> <br /> ADVERTENCIA: net/core/flow_dissector.c:1131 en __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053<br /> Traza de Llamadas:<br /> <br /> bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [en línea]<br /> __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157<br /> bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [en línea]<br /> bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [en línea]<br /> bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515<br /> xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388<br /> bpf_prog_run_xdp include/net/xdp.h:700 [en línea]<br /> bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421<br /> bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390<br /> bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703<br /> __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182<br /> __do_sys_bpf kernel/bpf/syscall.c:6274 [en línea]<br /> __se_sys_bpf kernel/bpf/syscall.c:6272 [en línea]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [en línea]<br /> do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> l2tp: evitar una carrera de datos en l2tp_tunnel_del_work()<br /> <br /> Deberíamos leer sk-&amp;gt;sk_socket solo cuando se trata de sockets del kernel.<br /> <br /> syzbot informó la siguiente carrera de datos:<br /> <br /> BUG: KCSAN: carrera de datos en l2tp_tunnel_del_work / sk_common_release<br /> <br /> escritura en 0xffff88811c182b20 de 8 bytes por la tarea 5365 en la cpu 0:<br /> sk_set_socket include/net/sock.h:2092 [inline]<br /> sock_orphan include/net/sock.h:2118 [inline]<br /> sk_common_release+0xae/0x230 net/core/sock.c:4003<br /> udp_lib_close+0x15/0x20 include/net/udp.h:325<br /> inet_release+0xce/0xf0 net/ipv4/af_inet.c:437<br /> __sock_release net/socket.c:662 [inline]<br /> sock_close+0x6b/0x150 net/socket.c:1455<br /> __fput+0x29b/0x650 fs/file_table.c:468<br /> ____fput+0x1c/0x30 fs/file_table.c:496<br /> task_work_run+0x131/0x1a0 kernel/task_work.c:233<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]<br /> exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75<br /> __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]<br /> syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]<br /> do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> lectura en 0xffff88811c182b20 de 8 bytes por la tarea 827 en la cpu 1:<br /> l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340<br /> worker_thread+0x582/0x770 kernel/workqueue.c:3421<br /> kthread+0x489/0x510 kernel/kthread.c:463<br /> ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> valor cambiado: 0xffff88811b818000 -&amp;gt; 0x0000000000000000

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mISDN: anotar condición de carrera de datos alrededor de dev-&amp;gt;work<br /> <br /> dev-&amp;gt;work puede ser releído sin bloqueo en mISDN_read() y mISDN_poll(). Añadir anotaciones READ_ONCE()/WRITE_ONCE().<br /> <br /> ERROR: KCSAN: condición de carrera de datos en mISDN_ioctl / mISDN_read<br /> <br /> escritura en 0xffff88812d848280 de 4 bytes por la tarea 10864 en la CPU 1:<br /> misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline]<br /> mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583<br /> __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583<br /> x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> lectura en 0xffff88812d848280 de 4 bytes por la tarea 10857 en la CPU 0:<br /> mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112<br /> do_loop_readv_writev fs/read_write.c:847 [inline]<br /> vfs_readv+0x3fb/0x690 fs/read_write.c:1020<br /> do_readv+0xe7/0x210 fs/read_write.c:1080<br /> __do_sys_readv fs/read_write.c:1165 [inline]<br /> __se_sys_readv fs/read_write.c:1162 [inline]<br /> __x64_sys_readv+0x45/0x50 fs/read_write.c:1162<br /> x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> valor cambiado: 0x00000000 -&amp;gt; 0x00000001

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> igc: Reducir el búfer de paquetes TX TSN de 7KB a 5KB por cola<br /> <br /> Los 7 KB anteriores por cola causaban bloqueos de la unidad TX bajo una carga pesada de marca de tiempo. La reducción a 5 KB evita estos bloqueos y coincide con la recomendación TSN en la Sección 7.5.4 del Manual de Usuario de SW I225/I226.<br /> <br /> Los 8 KB &amp;#39;liberados&amp;#39; por este cambio actualmente no se utilizan. Esta reducción no se espera que impacte el rendimiento, ya que el i226 está limitado por PCIe para paquetes TSN pequeños en lugar de estar limitado por el búfer TX.

En el kernel de Linux, la siguiente vulnerabilidad se ha resuelto:<br /> <br /> interconnect: debugfs: inicializar src_node y dst_node a cadenas vacías<br /> <br /> La API debugfs_create_str() asume que el puntero de cadena es NULL o apunta a memoria kmalloc() válida. Dejar el puntero sin inicializar puede causar problemas.<br /> <br /> Inicializar src_node y dst_node a cadenas vacías antes de crear las entradas debugfs para garantizar que las lecturas y escrituras sean seguras.