Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: userfaultfd: corregir comprobaciones para PMD enormes Serie de parches "userfaultfd: corregir ejecucións en torno a la comprobación pmd_trans_huge()", v2. El código pmd_trans_huge() en mfill_atomic() es incorrecto de tres maneras diferentes según la versión del kernel: 1. La comprobación pmd_trans_huge() es rápida y puede llevar a un BUG_ON() (si alcanza las dos ventanas de ejecución correctas) - He probado esto en una compilación del kernel con algunas llamadas mdelay() adicionales. Vea el mensaje de confirmación para obtener una descripción del escenario de ejecución. En kernels más antiguos (antes de 6.5), creo que el mismo error puede incluso teóricamente llevar a acceder a los contenidos de la página transhuge como una tabla de páginas si alcanza las 5 ventanas de ejecución estrechas correctas (no he probado este caso). 2. Como señaló Qi Zheng, pmd_trans_huge() no es suficiente para detectar PMD que no apuntan a tablas de páginas. En kernels más antiguos (anteriores a 6.5), solo tendrías que ganar una única ejecución bastante amplia para alcanzar esto. He probado esto en 6.1 estable haciendo una ejecución de migración (con un mdelay() parcheado en try_to_migrate()) contra UFFDIO_ZEROPAGE - en mi VM x86, eso causa un error de kernel en ptlock_ptr(). 3. En kernels más nuevos (>=6.5), para asignaciones shmem, khugepaged puede arrancar tablas de páginas de debajo de nosotros (aunque no lo he probado), así que creo que las comprobaciones BUG_ON() en mfill_atomic() son simplemente incorrectas. Decidí escribir dos correcciones separadas para estos (una corrección para los errores 1+2, una corrección para el error 3), de modo que la primera corrección pueda ser retroportada a kernels afectados por errores 1+2. Este parche (de 2): Esto corrige dos problemas. Descubrí que puede ocurrir la siguiente ejecución: mfill_atomic other thread ============ ============ pmdp_get_lockless() [reads none pmd] __pte_alloc [no-op] BUG_ON(pmd_none(*dst_pmd)) He verificado esto experimentalmente en un kernel con llamadas mdelay() adicionales; se activa BUG_ON(pmd_none(*dst_pmd)). En los kernels más nuevos que el commit 0d940a9b270b ("mm/pgtable: permitir que pte_offset_map[_lock]() falle"), esto no puede llevar a nada peor que un BUG_ON(), ya que los ayudantes de acceso a la tabla de páginas están manipulados para lidiar con la desaparición simultánea de tablas de páginas; pero en kernels más antiguos (<=6.4), creo que probablemente podríamos teóricamente pasar por alto las dos comprobaciones de BUG_ON() y terminar tratando una página enorme como una tabla de páginas. El segundo problema es que, como señaló Qi Zheng, hay otros tipos de PMD enormes que pmd_trans_huge() no puede detectar: PMD de devmap y PMD de intercambio (en particular, PMD de migración). En <=6.4, esto es peor que el primer problema: si mfill_atomic() se ejecuta en un PMD que contiene una entrada de migración (que solo requiere ganar una ejecución única y bastante amplia), pasará el PMD a pte_offset_map_lock(), que asume que el PMD apunta a una tabla de páginas. A continuación, se produce una ruptura: primero, el núcleo intenta tomar el bloqueo PTE (que se bloqueará o tal vez será peor si no hay una "página de estructura" para los bits de dirección en el PMD de la entrada de migración; creo que al menos en X86 no suele haber una "página de estructura" correspondiente gracias a la mitigación de inversión de PTE; amd64 se ve diferente). Si eso no se bloquea, el núcleo intentará escribir un PTE en lo que cree erróneamente que es una tabla de páginas. Como parte de la solución de estos problemas, elimine la verificación de pmd_trans_huge() antes de __pte_alloc(); eso es redundante, vamos a tener que verificar eso después de __pte_alloc() de todos modos. --- truncada ----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/osnoise: Utilizar una cpumask para saber qué subprocesos son kthreads El código start_kthread() y stop_thread() no siempre se llamaba con el interface_lock mantenido. Esto significa que la variable kthread podría cambiar inesperadamente provocando que se llamara a kthread_stop() en ella cuando no debería haberse hecho, lo que lleva a: while true; do rtla timerlat top -u -q & PID=$!; sleep 5; kill -INT $PID; sleep 0.001; kill -TERM $PID; wait $PID; hecho Provocando el siguiente OOPS: Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000010-0x0000000000000017] CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 No contaminado 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 RIP: 0010:hrtimer_active+0x58/0x300 Código: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 <0f> b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f RSP: 0018:ffff88811d97f940 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28 RBP: 000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60 R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28 FS: 000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0 Llamada Rastro: ? die_addr+0x40/0xa0 ? exc_general_protection+0x154/0x230 ? asm_exc_general_protection+0x26/0x30 ? hrtimer_active+0x58/0x300 ? __pfx_mutex_lock+0x10/0x10 ? __pfx_locks_remove_file+0x10/0x10 hrtimer_cancel+0x15/0x40 timerlat_fd_release+0x8e/0x1f0 ? security_file_release+0x43/0x80 __fput+0x372/0xb10 task_work_run+0x11e/0x1f0 ? _raw_spin_lock+0x85/0xe0 ? __pfx_task_work_run+0x10/0x10 ? objeto poison_slab+0x109/0x170 ? do_exit+0x7a0/0x24b0 do_exit+0x7bd/0x24b0 ? __pfx_migrate_enable+0x10/0x10 ? __pfx_do_exit+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x64/0x140 ? _raw_spin_lock_irq+0x86/0xe0 do_group_exit+0xb0/0x220 obtener_señal+0x17ba/0x1b50 ? vfs_read+0x179/0xa40 ? timerlat_fd_read+0x30b/0x9d0 ? __pfx_get_signal+0x10/0x10 ? __pfx_timerlat_fd_read+0x10/0x10 arch_do_signal_or_restart+0x8c/0x570 ? __pfx_arch_do_signal_or_restart+0x10/0x10 ? vfs_read+0x179/0xa40 ? ksys_read+0xfe/0x1d0 ? __pfx_ksys_read+0x10/0x10 syscall_salir_al_modo_usuario+0xbc/0x130 do_syscall_64+0x74/0x110 ? __pfx___rseq_handle_notify_resume+0x10/0x10 ? __pfx_ksys_read+0x10/0x10 ? fpregs_restore_userregs+0xdb/0x1e0 ? fpregs_restore_userregs+0xdb/0x1e0 ? syscall_salir_al_modo_usuario+0x116/0x130 ? do_syscall_64+0x74/0x110 ? do_syscall_64+0x74/0x110 ? do_syscall_64+0x74/0x110 entry_SYSCALL_64_after_hwframe+0x71/0x79 RIP: 0033:0x7ff0070eca9c Código: No se puede acceder a los bytes del código de operación en 0x7ff0070eca72. RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003 RBP: 00007ff006dffde0 R08: 000000000000000 R09: 00007ff000000ba0 R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003 R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008 Módulos vinculados en: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core ---[ fin del seguimiento 000000000000000 ]--- Esto se debe a que llamaría por error a kthread_stop() en un hilo de espacio de usuario, lo que haría que "salga" antes de que realmente salga. Dado que kthread ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: agregar comprobación de s->flags en alloc_tagging_slab_free_hook Cuando se habilitan CONFIG_MEMCG y CONFIG_KFENCE y CONFIG_KMEMLEAK, siempre aparece la siguiente advertencia. Esto se debe a que se produjo la siguiente pila de llamadas: mem_pool_alloc kmem_cache_alloc_noprof slab_alloc_node kfence_alloc Una vez que la asignación de kfence es exitosa, slab->obj_exts no estará vacío, porque ya se le ha asignado un valor en kfence_init_pool. Dado que en la función prepare_slab_obj_exts_hook, realizamos una comprobación de s->flags y (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE), la función alloc_tag_add no se llamará como resultado. Por lo tanto, ref->ct permanece NULL. Sin embargo, cuando llamamos a mem_pool_free, dado que obj_ext no está vacío, finalmente se invoca el escenario alloc_tag_sub. Aquí es donde se produce la advertencia. Por lo tanto, deberíamos agregar las comprobaciones correspondientes en alloc_tagging_slab_free_hook. Para el caso de __GFP_NO_OBJ_EXT, no vi el caso específico en el que se usa kfence, por lo que no agregaré la comprobación correspondiente en alloc_tagging_slab_free_hook por ahora. [ 3.734349] ------------[ cortar aquí ]------------ [ 3.734807] alloc_tag no se configuró [ 3.735129] ADVERTENCIA: CPU: 4 PID: 40 en ./include/linux/alloc_tag.h:130 kmem_cache_free+0x444/0x574 [ 3.735866] Módulos vinculados en: autofs4 [ 3.736211] CPU: 4 UID: 0 PID: 40 Comm: ksoftirqd/4 Contaminado: GW 6.11.0-rc3-dirty #1 [ 3.736969] Contaminado: [W]=WARN [ 3.737258] Nombre del hardware: QEMU KVM Virtual Machine, BIOS desconocido 2/2/2022 [ 3.737875] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3.738501] pc : kmem_cache_free+0x444/0x574 [ 3.738951] lr : kmem_cache_free+0x444/0x574 [ 3.739361] sp : ffff80008357bb60 [ 3.739693] x29: ffff80008357bb70 x28: 0000000000000000 x27: 0000000000000000 [ 3.740338] x26: ffff80008207f000 x25: ffff000b2eb2fd60 x24: ffff0000c0005700 [ 3.740982] x23: ffff8000804229e4 x22: ffff800082080000 x21: ffff800081756000 [ 3.741630] x20: fffffd7ff8253360 x19: 00000000000000a8 x18: ffffffffffffffffff [ 3.742274] x17: ffff800ab327f000 x16: ffff800083398000 x15: ffff800081756df0 [ 3.742919] x14: 0000000000000000 x13: 205d344320202020 x12: 5b5d373038343337 [ 3.743560] x11: ffff80008357b650 x10: 000000000000005d x9 : 00000000ff ffffd0 [3.744231] x8: 7f7f7f7f7f7f7f7f x7: ffff80008237bad0 x6: c0000000ffff7fff [3.744907] x5: ffff80008237ba78 x4: ffff8000820bbad0 x3: 00000000000000001 [ 3.745580] x2 : 68d66547c09f7800 x1 : 68d66547c09f7800 x0 : 0000000000000000 [ 3.746255] Rastreo de llamadas: [ 3.746530] kmem_cache_free+0x444/0x574 [ 3.746931] mem_pool_free+0x44/0xf4 [ 3.747306] free_object_rcu+0xc8/0xdc [ 3.747693] rcu_do_batch+0x234/0x8a4 [ 3.748075] rcu_core+0x230/0x3e4 [ 3.748424] rcu_core_si+0x14/0x1c [ 3.748780] handle_softirqs+0x134/0x378 [ 3.749189] run_ksoftirqd+0x70/0x9c [ 3.749560] smpboot_thread_fn+0x148/0x22c [ 3.749978] kthread+0x10c/0x118 [ 3.750323] ret_from_fork+0x10/0x20 [ 3.750696] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscache: eliminar fscache_cookie_lru_timer cuando fscache sale para evitar UAF fscache_cookie_lru_timer se inicializa cuando se inserta el módulo fscache, pero no se elimina cuando se elimina el módulo fscache. Si se llama a timer_reduce() antes de eliminar el módulo fscache, fscache_cookie_lru_timer se agregará a la lista de temporizadores de la CPU actual. Posteriormente, se activará un use after free en el softIRQ después de quitar el módulo fscache, de la siguiente manera: ======================================================================== ERROR: no se puede manejar el error de página para la dirección: fffffbfff803c9e9 PF: acceso de lectura del supervisor en modo kernel PF: error_code(0x0000) - página no presente PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Contaminado: GW 6.11.0-rc3 #855 Contaminado: [W]=ADVERTENCIA RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 Rastreo de llamadas: tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0 handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60 do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148 Módulos vinculados en: [última descarga: netfs] ======================================================================= Por lo tanto, elimine fscache_cookie_lru_timer al eliminar el módulo fscahe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar el denominador crb_pipes antes de usarlo [QUÉ Y CÓMO] Un denominador no puede ser 0 y se comprueba antes de usarlo. Esto soluciona 2 problemas de DIVIDE_BY_ZERO informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/rtas: Impedir la construcción del gadget Spectre v1 en sys_rtas() Smatch advierte: arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() advierte: posible problema de Spectre 'args.args' [r] (cap local) Las variables locales 'nargs' y 'nret' provienen directamente de un búfer proporcionado por el usuario y se usan como índices en una pequeña matriz basada en pila y como entradas para copy_to_user() después de que estén sujetas a verificaciones de límites. Utilice array_index_nospec() después de las verificaciones de límites para fijar estos valores para la ejecución especulativa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: bcm: Eliminar entrada proc cuando dev no está registrado. syzkaller informó una advertencia en bcm_connect() a continuación. [0] La repro llama a connect() a vxcan1, elimina vxcan1 y llama a connect() con ifindex == 0. Llamar a connect() para un socket BCM asigna una entrada proc. Luego, bcm_sk(sk)->bound se establece en 1 para evitar más connect(). Sin embargo, eliminar el dispositivo vinculado restablece bcm_sk(sk)->bound a 0 en bcm_notify(). El segundo connect() intenta asignar una entrada proc con el mismo nombre y establece NULL en bcm_sk(sk)->bcm_proc_read, filtrando la entrada proc original. Dado que la entrada proc solo está disponible para sockets conectados, limpiemos la entrada cuando el netdev vinculado no esté registrado. [0]: proc_dir_entry 'can-bcm/2456' ya está registrado ADVERTENCIA: CPU: 1 PID: 394 en fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375 Módulos vinculados en: CPU: 1 PID: 394 Comm: syz-executor403 No contaminado 6.10.0-rc7-g852e42cc2dd4 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375 Código: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48 RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246 RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0 R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [en línea] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [en línea] __se_sys_connect net/socket.c:2073 [en línea] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fbd708b0e5d Código: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040 R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098 R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 remove_proc_entry: elimina el directorio no vacío 'net/can-bcm', filtrando al menos '2456'

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar el denominador pbn_div antes de usarlo [QUÉ Y CÓMO] Un denominador no puede ser 0 y se comprueba antes de usarlo. Esto soluciona un problema DIVIDE_BY_ZERO informado por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: evitar particiones de longitud excesiva Evite montar sistemas de archivos en los que la partición supere los 32 bits utilizados para el número de bloque. También rehúse montar sistemas de archivos en los que la longitud de la partición sea tan grande que no podamos indexar bits de forma segura en un mapa de bits de bloques.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: protege las referencias a los parámetros de superbloque expuestos en sysfs Los búferes de superbloque de nilfs2 no solo se pueden sobrescribir en tiempo de ejecución para modificaciones/reparaciones, sino que también se intercambian regularmente, se reemplazan durante el cambio de tamaño e incluso se abandonan cuando se degradan a un lado debido a problemas con el dispositivo de respaldo. Por lo tanto, acceder a ellos requiere exclusión mutua utilizando el semáforo de lectura/escritura "nilfs->ns_sem". Algunos métodos de demostración del atributo sysfs leen este búfer de superbloque sin la exclusión mutua necesaria, lo que puede causar problemas con la desreferenciación de punteros y el acceso a la memoria, así que arréglelo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: se corrige el error de limpieza faltante en la recuperación de avance En una prueba de inyección de errores de una rutina para la recuperación en tiempo de montaje, KASAN encontró un error de use after free. Resultó que si la recuperación de datos se realizaba utilizando registros parciales creados por escrituras dsync, pero se producía un error antes de iniciar el escritor de registros para crear un punto de control recuperado, los inodos cuyos datos se habían recuperado se dejaban en la lista ns_dirty_files del objeto nilfs y no se liberaban. Solucione este problema limpiando los inodos que han leído los datos de recuperación si la rutina de recuperación falla a mitad de camino antes de que se inicie el escritor de registros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ila: llamar a nf_unregister_net_hooks() antes de que syzbot encuentre una lectura de uso posterior a la liberación en ila_nf_input [1] El problema aquí es que ila_xlat_exit_net() libera la tabla rhash y luego llama a nf_unregister_net_hooks(). Debería hacerse de forma inversa, con unsynchronous_rcu(). Esta es una buena combinación para un método pre_exit(). [1] ERROR: KASAN: use after free en rht_key_hashfn include/linux/rhashtable.h:159 [en línea] ERROR: KASAN: use after free en __rhashtable_lookup include/linux/rhashtable.h:604 [en línea] ERROR: KASAN: use after free en rhashtable_lookup include/linux/rhashtable.h:646 [en línea] ERROR: KASAN: use after free en rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 Lectura de tamaño 4 en la dirección ffff888064620008 por la tarea ksoftirqd/0/16 CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 No contaminado 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [en línea] __rhashtable_lookup include/linux/rhashtable.h:604 [en línea] rhashtable_lookup include/linux/rhashtable.h:646 [en línea] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [en línea] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [en línea] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [en línea] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [en línea] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [en línea] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [en línea] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 La dirección con errores pertenece a la página física: page: refcount:0 mapcount:0 mapping:0000000000000000 índice:0x0 pfn:0x64620 indicadores: 0xfff00000000000(nodo=0|zona=1|lastcpupid=0x7ff) tipo_página: 0xbfffffff(amigo) sin procesar: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000 sin procesar: 000000000000000 000000000000003 00000000bfffffff 0000000000000000 página volcada porque: kasan: se detectó un acceso incorrecto page_owner rastrea la página como liberada última página asignada mediante orden 3, migrantstype inamovible, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (ejecutor del sistema), ts 73611328570, free_ts 618981657187 establecer_propietario_de_página include/linux/page_owner.h:32 [en línea] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 preparar_nueva_página mm/page_alloc.c:1501 [en línea] obtener_página_de_lista_libre+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [en línea] alloc_pages_node_noprof include/linux/gfp.h:296 [en línea] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [en línea] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [en línea] ---truncado---