Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/writeback: corrige la posible división por cero en wb_dirty_limits(), nuevamente (struct dirty_throttle_control *)->thresh es un largo sin firmar, pero se pasa como argumento del divisor u32 a div_u64(). En arquitecturas donde la longitud sin firmar es de 64 bytes, el argumento se truncará implícitamente. Utilice div64_u64() en lugar de div_u64() para que el valor utilizado en la comprobación "¿Es esta una división segura" sea el mismo que el divisor? Además, elimine la conversión redundante del numerador a u64, ya que eso debería suceder implícitamente. Esto sería difícil de explotar en el dominio memcg, dado el uso de la aritmética basada en proporciones domain_drity_limits(), pero es mucho más fácil en el dominio de reescritura global con un dispositivo de respaldo BDI_CAP_STRICTLIMIT, usando, por ejemplo, vm.dirty_bytes=(1<<32)*PAGE_SIZE de modo que dtc->thresh == (1<<32)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/kasan: limitar el aumento del tamaño del subproceso KASAN a 32 KB. Se considera que KASAN aumenta el uso de la pila, hasta el punto de que se informó que provoca un desbordamiento de la pila en algunas máquinas de 32 bits ( ver enlace). Para evitar desbordamientos, el tamaño de la pila se duplicó para las compilaciones de KASAN en el commit 3e8635fb2e07 ("powerpc/kasan: Forzar el aumento del tamaño del subproceso con KASAN"). Sin embargo, con un tamaño de pila de 32 KB para empezar, la duplicación conduce a una pila de 64 KB, lo que provoca errores de compilación: arch/powerpc/kernel/switch.S:249: Error: operando fuera de rango (0x000000000000fe50 no está entre 0xffffffffffff8000 y 0x00000000000007fff) Aunque el conjunto podría modificarse, en la práctica una pila de 32 KB parece suficiente incluso para compilaciones KASAN; el uso adicional parece estar en el rango de 2 a 3 KB para una compilación KASAN de 64 bits. Por lo tanto, solo aumente la pila para KASAN si el tamaño de la pila es <32 KB.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige un posible error en end_buffer_async_write Según un informe de syzbot, end_buffer_async_write(), que maneja la finalización de las escrituras del dispositivo de bloque, puede detectar una condición anormal del indicador async_write del búfer y causar un Error BUG_ON al usar nilfs2. Nilfs2 en sí no usa end_buffer_async_write(). Pero el indicador async_write ahora se usa como marcador en el commit 7f42ec394156 ("nilfs2: soluciona el problema con la condición de ejecución de competencia entre segmentos por bloques sucios") como un medio para resolver la inserción de lista doble de bloques sucios en nilfs_lookup_dirty_data_buffers() y nilfs_lookup_node_buffers( ) y el accidente resultante. Esta modificación es segura siempre que se utilice para datos de archivos y bloques de nodos de árbol b donde las cachés de páginas sean independientes. Sin embargo, era irrelevante y redundante introducir también async_write para el resumen de segmento y los bloques súper raíz que comparten buffers con el dispositivo de respaldo. Esto generó la posibilidad de que la verificación BUG_ON en end_buffer_async_write fallara como se describe anteriormente, si se produjeran reescrituras independientes del dispositivo de respaldo en paralelo. El uso de async_write para buffers de resumen de segmentos ya se eliminó en un cambio anterior. Solucione este problema eliminando la manipulación del indicador async_write para el búfer de bloque súper raíz restante.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xen/events: cierre evtchn después de la limpieza del mapeo. Shutdown_pirq y startup_pirq no están tomando irq_mapping_update_lock porque no pueden hacerlo debido a la inversión de bloqueo. Ambos se llaman con el irq_desc->lock en curso. Sin embargo, el orden de bloqueo es primero irq_mapping_update_lock y luego irq_desc->lock. Esto abre múltiples ejecucións: - Shutdown_pirq puede ser interrumpido por una función que asigna un canal de evento: CPU0 CPU1 Shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> devuelve el evtchn e set_evtchn_to_irq(e, irq) recién liberado} xen_irq_info_cleanup() { set_evtchn_to_irq( e, -1) } } Supongamos que aquí el canal de eventos e se refiere aquí al mismo número de canal de eventos. Después de esta ejecución, el mapeo evtchn_to_irq para e no es válido (-1). - __startup_pirq compite con __unbind_from_irq de manera similar. Debido a que __startup_pirq no toma irq_mapping_update_lock, puede tomar el evtchn que __unbind_from_irq está liberando y limpiando actualmente. En este caso, aunque el canal de eventos esté asignado, su asignación se puede desarmar en evtchn_to_irq. La solución es limpiar primero las asignaciones y luego cerrar el canal de eventos. De esta manera, cuando se asigna un canal de eventos, se garantiza que sus posibles asignaciones anteriores de evtchn_to_irq ya no estarán configuradas. Este es también el orden inverso de la asignación donde primero se asigna el canal de evento y luego se configuran las asignaciones. En un kernel 5.10 antes de commit 3fcdaf3d7634 ("xen/events: modificar interfaces internas [un]bind"), encontramos un ERROR como el siguiente durante el sondeo de dispositivos NVMe. El problema es que durante nvme_setup_io_queues, se llama a pci_free_irq para cada dispositivo, lo que resulta en una llamada a Shutdown_pirq. Por lo tanto, con muchos dispositivos nvme es probable que alcance esta ejecución durante el arranque porque habrá múltiples llamadas a Shutdown_pirq y startup_pirq que se ejecutan potencialmente en paralelo. ------------[ cortar aquí ]------------ blkfront: xvda: barrera o descarga: deshabilitado; subvenciones persistentes: habilitadas; descriptores indirectos: habilitado; búfer de rebote: ¡ERROR del kernel habilitado en drivers/xen/events/events_base.c:499! código de operación no válido: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 No contaminado 5.10.201-191.748.amzn2.x86_64 #1 Nombre de hardware: Xen HVM domU, BIOS 4.11.amazon 24/08 /2006 Cola de trabajo: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Código: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 00000000000 00000 R09: ffffffff82d72b00 R10: 00000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 00000000000000000 R14: 00000000ffffffff R15 : 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000000 CR3: 0000000002610001 CR4: 000000000017 06e0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? show_trace_log_lvl+0x1c1/0x2d9? show_trace_log_lvl+0x1c1/0x2d9? set_affinity_irq+0xdc/0x1c0? __die_body.cold+0x8/0xd ? morir+0x2b/0x50 ? do_trap+0x90/0x110? bind_evtchn_to_cpu+0xdf/0xf0? do_error_trap+0x65/0x80? bind_evtchn_to_cpu+0xdf/0xf0? exc_invalid_op+0x4e/0x70? bind_evtchn_to_cpu+0xdf/0xf0? asm_exc_invalid_op+0x12/0x20? bind_evtchn_to_cpu+0xdf/0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs,hugetlb: corrige la desreferencia del puntero NULL en hugetlbs_fill_super Al configurar un SYSTEM de archivos de Hugetlb a través de la llamada al SYSTEM fsconfig(), existe una posible desreferencia de NULL en hugetlbfs_fill_super() causada por la asignación de NULL a ctx. ->hstate en hugetlbfs_parse_param() cuando el tamaño de página solicitado no es válido. Por ejemplo: siguiendo los siguientes pasos: fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC); fsconfig(fd, FSCONFIG_SET_STRING, "tamaño de página", "1024", 0); fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0); Dado que el "tamaño de página" solicitado no es válido, ctxt->hstate será reemplazado por NULL, perdiendo su valor anterior, e imprimiremos un error: ... ... case Opt_pagesize: ps = memparse(param->string, &descansar); ctx->hestado = h; if (!ctx->hstate) { pr_err("Tamaño de página no admitido %lu MB\n", ps / SZ_1M); devolver -EINVAL; } devolver 0; ... ... Esto es un problema porque más adelante eliminaremos la referencia a ctxt->hstate en hugetlbfs_fill_super() ... ... sb->s_blocksize = huge_page_size(ctx->hstate); ... ... Causando debajo Ups. Solucione este problema reemplazando el valor cxt->hstate solo cuando se sepa que el tamaño de página es válido. kernel: hugetlbfs: Tamaño de página no admitido 0 MB kernel: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000028 kernel: #PF: acceso de lectura del supervisor en modo kernel kernel: #PF: código_error(0x0000) - página no presente kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Ups: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Contaminado: GE 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344 Kernel aabc35190ae8f: Nombre del hardware: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 03/05/2017 kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Código: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff R DI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: fffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7 000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Seguimiento de llamadas: kernel: kernel: ? __die_body+0x1a/0x60 núcleo: ? page_fault_oops+0x16f/0x4a0 núcleo:? search_bpf_extables+0x65/0x70 núcleo:? fixup_exception+0x22/0x310 kernel:? exc_page_fault+0x69/0x150 núcleo:? asm_exc_page_fault+0x22/0x30 núcleo:? __pfx_hugetlbfs_fill_super+0x10/0x10 núcleo:? núcleo enormetlbfs_fill_super+0xb4/0x1a0:? enormetlbfs_fill_super+0x28/0x1a0 kernel:? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: vfs_get_super+0x40/0xa0 kernel:? __pfx_bpf_lsm_capable+0x10/0x10 kernel: vfs_get_tree+0x25/0xd0 kernel: vfs_cmd_create+0x64/0xe0 kernel: __x64_sys_fsconfig+0x395/0x410 kernel: do_syscall_64+0x80/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel:? do_syscall_64+0x8d/0x160 núcleo:? syscall_exit_to_user_mode+0x82/0x240 kernel:? do_syscall_64+0x8d/0x160 núcleo:? exc_page_fault+0x69/0x150 kernel: Entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Código: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 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 97 96 0d 00 f7 d8 64 89 01 48 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: evita el use-after-free en encode_cap_msg() En fs/ceph/caps.c, en encode_cap_msg(), KASAN detectó el error "use after free" en este línea - 'ceph_buffer_get(arg->xattr_buf);'. Esto implica que antes de que el recuento pudiera incrementarse aquí, fue liberado. En el mismo archivo, en "handle_cap_grant()", el refcount se reduce en esta línea: 'ceph_buffer_put(ci->i_xattrs.blob);'. Parece que se produjo una ejecución y la última línea liberó el recurso antes de que la primera línea pudiera incrementarlo. __send_cap() llama a encode_cap_msg() y ceph_check_caps() llama a __send_cap() después de llamar a __prep_cap(). __prep_cap() es donde arg->xattr_buf se asigna a ci->i_xattrs.blob. Este es el punto donde se debe aumentar el recuento para evitar el error "use after free".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: protege las actualizaciones de los contadores de estadísticas de 64 bits. Como se explica en un comentario en , el lado de escritura de la estructura u64_stats_sync debe garantizar la exclusión mutua, o uno La actualización de seqcount podría perderse en plataformas de 32 bits, bloqueando así a los lectores para siempre. Estos bloqueos se han observado en el mundo real después de que stmmac_xmit() en una CPU compitiera con stmmac_napi_poll_tx() en otra CPU. Para solucionar el problema sin introducir un nuevo bloqueo, divida la estática en tres partes: 1. campos actualizados solo bajo el bloqueo de la cola de transmisión, 2. campos actualizados solo durante la encuesta NAPI, 3. campos actualizados solo desde el contexto de interrupción, Actualizaciones de los campos en los dos primeros grupos ya están serializados a través de otras cerraduras. Basta con dividir la estructura existente u64_stats_sync para que cada grupo tenga el suyo propio. Tenga en cuenta que tx_set_ic_bit se actualiza desde ambos contextos. Divida este contador para que cada contexto tenga el suyo y calcule su suma para obtener el valor total en stmmac_get_ethtool_stats(). Para el tercer grupo, diferentes CPU pueden procesar múltiples interrupciones al mismo tiempo, pero las interrupciones en la misma CPU no se anidarán. Mueva los campos de este grupo a una estructura por CPU stmmac_pcpu_stats recién creada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: corrige la dependencia de bloqueo circular La regla dentro de kvm exige que vcpu->mutex se tome *dentro* de kvm->lock. La regla es violada por pkvm_create_hyp_vm() que adquiere el bloqueo kvm->mientras ya mantiene el bloqueo vcpu->mutex de kvm_vcpu_ioctl(). Evite por completo la dependencia del bloqueo circular protegiendo el identificador hyp vm con config_lock, de forma muy similar a como lo hacemos con otras formas de datos con alcance de VM.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb: se corrigió la regresión en las escrituras cuando se negoció un tamaño de escritura máximo no estándar. La conversión a netfs en el kernel 6.3 provocó una regresión cuando el servidor estableció el tamaño de escritura máximo en un valor inesperado. que no es un múltiplo de 4096 (de manera similar, si el usuario anula el tamaño máximo de escritura configurando el parámetro de montaje "wsize", pero lo establece en un valor que no es un múltiplo de 4096). Cuando el tamaño de escritura negociado no es un múltiplo de 4096, el código netfs puede omitir el final de la página final al realizar escrituras secuenciales grandes, lo que provoca corrupción de datos. Esta sección de código se está reescribiendo/eliminando debido a un gran cambio en netfs, pero hasta ese momento (es decir, para el kernel 6.3 hasta ahora) no podemos admitir tamaños máximos de escritura no estándar. Agregue una advertencia si un usuario especifica un wsize en el montaje que no es un múltiplo de 4096 (y redondea hacia abajo), también agregue un cambio donde redondeamos hacia abajo el tamaño máximo de escritura si el servidor negocia un valor que no es un múltiplo de 4096 ( también tenemos que comprobar que no lo redondeamos a cero).

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: wifi: iwlwifi: mvm: soluciona un fallo cuando nos quedamos sin estaciones Una herramienta DoS que inyecta un montón de marcos de autenticación hacía que nuestro AP fallara. La función iwl_mvm_is_dup() no pudo encontrar los datos dup_data por cola que no estaban asignados. La causa principal de esto es que nos quedamos sin estaciones en el firmware y realmente no agregamos la estación al firmware, pero no devolvimos un error a mac80211. Mac80211 estaba pensando que teníamos la estación y debido a eso, sta_info::uploaded se configuró en 1. Esto permitió que ieee80211_find_sta_by_ifaddr() devolviera un objeto de estación válido, pero que ieee80211_sta no tenía ningún objeto iwl_mvm_sta inicializado y eso causó el bloqueo. Mencioné anteriormente cuando obtuvimos Rx en esa estación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: corrige el error de doble liberación El almacenamiento de los datos de registro de PC TLV no se realizó como el resto del almacenamiento en el área drv->fw, que se borra en el fin de la desasignación. Por lo tanto, la liberación también debe realizarse de manera diferente, anulándolo explícitamente después de la liberación, ya que de lo contrario hay un desagradable error de doble liberación aquí si un archivo no se carga después de haber sido analizado y obtenemos otra liberación más tarde (por ejemplo porque no existe ningún otro archivo). Solucione el problema agregando la asignación NULL que falta.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: ccp - Corrige la desreferencia del puntero nulo en __sev_platform_shutdown_locked El dispositivo de la plataforma SEV se puede apagar con un psp_master nulo, por ejemplo, usando DEBUG_TEST_DRIVER_REMOVE. Encontrado usando KASAN: [ 137.148210] ccp 0000:23:00.1: dispositivo de habilitación (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no hay colas de comandos disponibles [ 137.170598] ccp 0000:23:00.1: sev habilitado [ 13 7.174645 ] ccp 0000:23:00.1: psp habilitado [137.178890] falla de protección general, probablemente para dirección no canónica 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [137.182693] KASAN: null-ptr-deref en rango [0x00 000000000000f0- 0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 No contaminado 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.1826 93] Código: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 00000000000000000 RC X: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R0 8 : 0000000000000000 R09: ffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881 e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:00000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693 ] Seguimiento de llamadas: [ 137.182693] [ 137.182693] ? show_regs+0x6c/0x80 [137.182693]? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [137.182693]? asm_exc_general_protection+0x2b/0x30 [137.182693]? __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [ 137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0 xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [ 137.182693] device_remove+0xc7/0x170 [ 137.182693]realmente_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.18 2693] ? __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10 [137.182693]? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [137.182693]? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_ registro_controlador+0x1d6/0x2a0 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693]? esrt_sysfs_init+0x1cd/0x5d0 [137.182693]? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [137.182693]? parameq+0x80/0xf0 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693]? __kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernel_init_freeable+0x92d/0x1050 [137.182693]? kasan_populate_vmalloc_pte+0x171/0x190 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693] kernel_init_freeable+0xa64/0x1050 [137.182693]? __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x1 ---truncado---