Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: PRM: Buscar bloque EFI_MEMORY_RUNTIME para el controlador PRM y el contexto PRMT necesita encontrar el tipo correcto de bloque para traducir la asignación PA-VA para los servicios de tiempo de ejecución EFI. El problema surge porque PRMT encuentra un bloque de tipo EFI_CONVENTIONAL_MEMORY, que no es apropiado para los servicios de tiempo de ejecución como se describe en la Sección 2.2.2 (Servicios de tiempo de ejecución) de la Especificación UEFI [1]. Dado que el controlador PRM es un tipo de servicio de tiempo de ejecución, esto provoca una excepción cuando se llama al controlador PRM. [Error de firmware]: No se puede manejar la solicitud de paginación en el servicio de tiempo de ejecución de EFI ADVERTENCIA: CPU: 22 PID: 4330 en drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Rastreo de llamadas: deje que PRMT encuentre un bloque con EFI_MEMORY_RUNTIME para el controlador PRM y el contexto PRM. Si no se encuentra ningún bloque adecuado, se imprimirá un mensaje de advertencia, pero el procedimiento continúa para administrar el siguiente controlador PRM. Sin embargo, si el controlador PRM se llama realmente sin la asignación adecuada, se produciría un error durante el manejo de errores. Al utilizar los tipos de memoria correctos para los servicios de tiempo de ejecución, asegúrese de que el controlador PRM y el contexto estén correctamente mapeados en el espacio de direcciones virtuales durante el tiempo de ejecución, lo que evita el error de solicitud de paginación. El problema es que el controlador PRM solo puede usar la memoria que el firmware ha reasignado para el tiempo de ejecución, por lo que la región debe tener el atributo EFI_MEMORY_RUNTIME. [ rjw: Tema y ediciones del registro de cambios ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: validar el prefijo de la nueva SA usando la familia de SA cuando sel.family no está configurado Esto expande la validación introducida en el commit 07bf7908950a ("xfrm: validar las longitudes de prefijo de dirección en el selector xfrm"). syzbot creó una SA con usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Debido al selector AF_UNSPEC, verificar_newsa_info no pone límites en prefixlen_{s,d}. Pero luego copy_from_user_state establece x->sel.family en usersa.family (AF_INET). Realice la misma conversión en verificar_newsa_info antes de validar prefixlen_{s,d}, ya que así es como se usará prefixlen más adelante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: se corrige el uso de un valor no inicializado en udf_get_fileshortad. Se comprueba si hay desbordamiento al calcular alen en udf_current_aext para mitigar el uso posterior de un valor no inicializado en udf_get_fileshortad. Error de KMSAN[1]. Después de aplicar el parche, el reproductor no activó ningún problema[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeon_ep: Agregar manejo de fallas de asignación de SKB en __octep_oq_process_rx() build_skb() devuelve NULL en caso de una falla de asignación de memoria, por lo que se maneja dentro de __octep_oq_process_rx() para evitar la desreferencia del puntero NULL. __octep_oq_process_rx() es llamado durante el sondeo NAPI por el controlador. Si la asignación de skb falla, sigue extrayendo paquetes de la cola DMA de Rx: no deberíamos interrumpir el sondeo inmediatamente y, por lo tanto, indicar falsamente a octep_napi_poll() que la presión de Rx está disminuyendo. Como no hay un skb asociado en este caso, no procesa los paquetes y no los empuja hacia arriba en la pila de red: se omiten. Se implementa una función auxiliar para desmapear/vaciar todos los buferes de fragmentos utilizados por el paquete descartado. El contador 'alloc_failures' se incrementa para marcar el error de asignación de skb en las estadísticas del controlador. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Arreglar la inicialización de la máscara de bits del comando La máscara de bits del comando tiene un bit dedicado para el comando MANAGE_PAGES, este bit no se inicializa durante la inicialización de la máscara de bits del comando, solo durante MANAGE_PAGES. Además, mlx5_cmd_trigger_completions() también intenta activar la finalización del comando MANAGE_PAGES. Por lo tanto, en caso de que se produzca un error de estado antes de que se haya invocado cualquier comando MANAGE_PAGES (por ejemplo, durante mlx5_enable_hca()), mlx5_cmd_trigger_completions() intentará activar la finalización del comando MANAGE_PAGES, lo que dará como resultado un error null-ptr-deref.[1] Arréglalo inicializando la máscara de bits del comando correctamente. Mientras lo haces, reescribe el código para una mejor comprensión. [1] ERROR: KASAN: null-ptr-deref en mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core] Escritura de tamaño 4 en la dirección 0000000000000214 por la tarea kworker/u96:2/12078 CPU: 10 PID: 12078 Comm: kworker/u96:2 No contaminado 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Cola de trabajo: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Seguimiento de llamadas: dump_stack_lvl+0x7e/0xc0 kasan_report+0xb9/0xf0 kasan_check_range+0xec/0x190 mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core] mlx5_cmd_flush+0x94/0x240 [mlx5_core] enter_error_state+0x6c/0xd0 [mlx5_core] mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core] process_one_work+0x787/0x1490 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? asignar_trabajo+0x168/0x240 subproceso_trabajador+0x586/0xd30 ? subproceso_rescatador+0xae0/0xae0 subproceso_k+0x2df/0x3b0 ? subproceso_k_completo_y_salir+0x20/0x20 ret_de_la_bifurcación+0x2d/0x70 ? subproceso_k_completo_y_salir+0x20/0x20 ret_de_la_bifurcación_asm+0x11/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: bnep: corrige wild-memory-access en proto_unregister Hay un problema como el siguiente: KASAN: tal vez wild-memory-access en el rango [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: GW RIP: 0010:proto_unregister+0xee/0x400 Seguimiento de llamadas: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Como bnep_init() ignora el valor de retorno de bnep_sock_init(), y bnep_sock_init() limpiará Todos los recursos. Luego, cuando se elimine el módulo bnep, se llamará a bnep_sock_cleanup() para limpiar el recurso de Sock. Para resolver el problema anterior, simplemente devuelva el valor de retorno de bnep_sock_init() en bnep_exit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: altmode debería mantener la referencia al padre La versión del dispositivo altmode hace referencia a su dispositivo padre, pero sin mantener una referencia a él. Al registrar el altmode, se obtiene una referencia al padre y se coloca en la función de lanzamiento. Antes de esta corrección, al usar CONFIG_DEBUG_KOBJECT_RELEASE, vemos problemas como este: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, padre 0000000000000000 (retrasado 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, padre 0000000000000000 (retrasado 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, padre 000000000000000 (retrasado 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, padre 0000000000000000 (retrasado 3000) [ 46.612867] ======================================================================= [ 46.613402] ERROR: KASAN: slab-use-after-free en typec_altmode_release+0x38/0x129 [ 46.614003] Lectura de tamaño 8 en la dirección ffff8880057b9118 por la tarea kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 No contaminado 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Cola de trabajo: eventos kobject_delayed_cleanup [ 46.616446] Seguimiento de llamadas: [ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? proceso_trabajo_programado+0x3cb/0x85f [ 46.620185] tipoc_modo_alt_release+0x38/0x129 [ 46.620537] ? proceso_trabajo_programado+0x3cb/0x85f [ 46.620907] dispositivo_release+0xaf/0xf2 [ 46.621206] limpieza_retrasada_de_objetos+0x13b/0x17a [ 46.621584] proceso_trabajo_programado+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] subproceso de trabajo+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] [ 46.625953] [ 46.626056] Asignado por la tarea 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Liberado por la tarea 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir OOB al crear una solicitud SMB2_IOCTL Al usar cifrado, ya sea aplicado por el servidor o al usar la opción de montaje 'seal', el cliente comprimirá todos los buffers de solicitud compuestos para el cifrado en un solo iov en smb2_set_next_command(). SMB2_ioctl_init() asigna un pequeño búfer (448 bytes) para contener la solicitud SMB2_IOCTL en el primer iov, y si el usuario pasa un búfer de entrada que es mayor a 328 bytes, smb2_set_next_command() terminará escribiendo el final de @rqst->iov[0].iov_base como se muestra a continuación: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link ERROR: KASAN: slab-out-of-bounds en smb2_set_next_command.cold+0x1d6/0x24c [cifs] Escritura de tamaño 4116 en la dirección ffff8881148fcab8 por tarea ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln No contaminado 6.12.0-rc3 #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? vfs_symlink+0x1a1/0x2c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] ? smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? __buscar_bloqueo_mantenido+0x8a/0xa0 ? __hlock_class+0x32/0xb0 ? __ruta_de_compilación_desde_dentry_prefijo_opcional+0x19d/0x2e0 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? permiso_genérico+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entrada_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: core: Corregir null-ptr-deref en target_alloc_device() KASAN ha informado de un problema de null-ptr-deref: ERROR: KASAN: null-ptr-deref en target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e En target_alloc_device(), si falla la asignación de memoria para las colas dev, dev se liberará mediante dev->transport->free_device(), pero dev->transport no se inicializa en ese momento, lo que generará un problema de referencia de puntero nulo. Se soluciona este error liberando dev con hba->backend->ops->free_device().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp/dccp: No use timer_pending() en reqsk_queue_unlink(). Martin KaFai Lau informó de un use-after-free [0] en reqsk_timer_handler(). """ Estamos viendo un use-after-free de un programa bpf adjunto a trace_tcp_retransmit_synack. El programa pasa el req->sk al ayudante del kernel bpf_sk_storage_get_tracing que comprueba si hay valores nulos antes de usarlo. """ El commit 83fccfc3940c ("inet: soluciona un posible bloqueo en reqsk_queue_unlink()") agregó timer_pending() en reqsk_queue_unlink() para no llamar a del_timer_sync() desde reqsk_timer_handler(), pero introdujo una pequeña ventana de ejecución. Antes de que se llame al temporizador, expire_timers() llama a detach_timer(timer, true) para borrar timer->entry.pprev y lo marca como no pendiente. Si reqsk_queue_unlink() comprueba timer_pending() justo después de que expire_timers() llame a detach_timer(), TCP no detectará del_timer_sync(); el temporizador reqsk seguirá funcionando y enviará varios SYN+ACK hasta que expire. El UAF informado podría ocurrir si se cierra req->sk antes de la expiración del temporizador, que es 63 s por defecto. El escenario sería 1. inet_csk_complete_hashdance() llama a inet_csk_reqsk_queue_drop(), pero se omite del_timer_sync() 2. se ejecuta el temporizador reqsk y se programa nuevamente 3. se acepta req->sk y reqsk_put() decrementa rsk_refcnt, pero el temporizador reqsk aún tiene otro, e inet_csk_accept() no borra req->sk para sockets que no sean TFO 4. se cierra sk 5. se ejecuta nuevamente el temporizador reqsk y BPF toca req->sk No usemos timer_pending() pasando el contexto del llamador a __inet_csk_reqsk_queue_drop(). Tenga en cuenta que el temporizador reqsk está fijado, por lo que el problema no ocurre en la mayoría de los casos de uso. [1] [0] ERROR: KFENCE: lectura de use-after-free en bpf_sk_storage_get_tracing+0x2e/0x1b0 Lectura de use-after-free en 0x00000000a891fb3a (en kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, tamaño=2376, caché=TCPv6 asignado por la tarea 0 en la CPU 9 en 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb liberado por la tarea 0 en la CPU 9 a las 260507.927527 s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpu_idle_entrada_estado+0xfb/0x273 cpu_inicio_entrada+0x15e/0x260 inicio_secundario+0x8a/0x90 inicio_secundario_64_sin_verificación+0xfa/0xfb

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Corregir error de desplazamiento fuera de los límites Corrige un error de desplazamiento fuera de los límites informado por UBSAN al ejecutar una máquina virtual con un kernel de host habilitado para MTE. UBSAN: desplazamiento fuera de los límites en arch/arm64/kvm/sys_regs.c:1988:14 el exponente de desplazamiento 33 es demasiado grande para el tipo de 32 bits 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm No contaminado 6.12.0-rc2 #34 Nombre del hardware: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 14/10/2024 Seguimiento de llamadas: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invocar_llamada_al_sistema+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/core: Deshabilitar la asignación de páginas en task_tick_mm_cid() Con KASAN y PREEMPT_RT habilitados, llamar a task_work_add() en task_tick_mm_cid() puede causar el siguiente splat. [ 63.696416] ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe [ 63.696416] preempt_count: 10001, esperado: 0 [ 63.696416] Profundidad de anidación de RCU: 1, esperado: 1 Este problema es causado por el siguiente seguimiento de llamada. sched_tick() [ adquirir rq->__lock ] -> task_tick_mm_cid() -> task_work_add() -> __kasan_record_aux_stack() -> kasan_save_stack() -> stack_depot_save_flags() -> alloc_pages_mpol_noprof() -> __alloc_pages_noprof() -> get_page_from_freelist() -> rmqueue() -> rmqueue_pcplist() -> __rmqueue_pcplist() -> rmqueue_bulk() -> rt_spin_lock() El bloqueo rq es un raw_spinlock_t. No podemos dormir mientras lo mantenemos. Es decir, no podemos llamar a alloc_pages() en stack_depot_save_flags(). La función task_tick_mm_cid() con su llamada task_work_add() fue introducida por el commit 223baf9d17f2 ("sched: Fix performance regression presented by mm_cid") en el kernel v6.4. Afortunadamente, hay una variante kasan_record_aux_stack_noalloc() que llama a stack_depot_save_flags() pero no le permite asignar nuevas páginas. Para permitir que task_tick_mm_cid() use task_work sin asignación de páginas, se agrega un nuevo indicador TWAF_NO_ALLOC para habilitar la llamada a kasan_record_aux_stack_noalloc() en lugar de kasan_record_aux_stack() si está configurado. La función task_tick_mm_cid() se modifica para agregar este nuevo indicador. La posible desventaja es la falta de seguimiento de pila en un informe KASAN debido a la nueva asignación de página requerida cuando se llama a task_work_add_noallloc(), lo que debería ser poco común.