Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/xe/pf: Corrección de la inicialización de sysfs<br /> <br /> En caso de fallo de devm_add_action_or_reset(), la acción de limpieza proporcionada se ejecutará inmediatamente en el kobject aún no inicializado. Esto puede provocar errores como:<br /> <br /> [ ] kobject: &amp;#39;(null)&amp;#39; (ff110001393608e0): no está inicializado, sin embargo, se está llamando a kobject_put().<br /> [ ] ADVERTENCIA: lib/kobject.c:734 en kobject_put+0xd9/0x250, CPU#0: kworker/0:0/9<br /> [ ] RIP: 0010:kobject_put+0xdf/0x250<br /> [ ] Call Trace:<br /> [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe]<br /> [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe]<br /> [ ] xe_sriov_init_late+0x5f/0x2c0 [xe]<br /> [ ] xe_device_probe+0x5f2/0xc20 [xe]<br /> [ ] xe_pci_probe+0x396/0x610 [xe]<br /> [ ] local_pci_probe+0x47/0xb0<br /> <br /> [ ] refcount_t: desbordamiento negativo; uso después de liberación.<br /> [ ] ADVERTENCIA: lib/refcount.c:28 en refcount_warn_saturate+0x68/0xb0, CPU#0: kworker/0:0/9<br /> [ ] RIP: 0010:refcount_warn_saturate+0x68/0xb0<br /> [ ] Call Trace:<br /> [ ] kobject_put+0x174/0x250<br /> [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe]<br /> [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe]<br /> [ ] xe_sriov_init_late+0x5f/0x2c0 [xe]<br /> [ ] xe_device_probe+0x5f2/0xc20 [xe]<br /> [ ] xe_pci_probe+0x396/0x610 [xe]<br /> [ ] local_pci_probe+0x47/0xb0<br /> <br /> Esto se soluciona llamando a kobject_init() y kobject_add() por separado y registrando la acción de limpieza después de que el kobject esté inicializado.<br /> <br /> También se hace que este registro de limpieza sea parte del asistente de creación para corregir otro error, ya que en el bucle estábamos pasando incorrectamente el kobject padre al registrar la acción de limpieza, y esto resultó en algunas fugas no detectadas.<br /> <br /> (seleccionado de la confirmación 98b16727f07e26a5d4de84d88805ce7ffcfdd324)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> pstore/ram: corrige desbordamiento de búfer en persistent_ram_save_old()<br /> <br /> persistent_ram_save_old() puede ser llamada múltiples veces para la misma persistent_ram_zone (por ejemplo, a través de ramoops_pstore_read -&gt; ramoops_get_next_prz para registros PSTORE_TYPE_DMESG).<br /> <br /> Actualmente, la función solo asigna prz-&gt;old_log cuando es NULL, pero actualiza incondicionalmente prz-&gt;old_log_size al tamaño de búfer actual y luego realiza memcpy_fromio() usando este nuevo tamaño. Si el tamaño del búfer ha crecido desde la primera asignación (lo que puede ocurrir en diferentes ciclos de arranque del kernel), esto lleva a:<br /> <br /> 1. Un desbordamiento de búfer de pila (escritura OOB) en las llamadas a memcpy_fromio()<br /> 2. Una lectura OOB posterior cuando ramoops_pstore_read() accede al búfer usando el old_log_size incorrecto (más grande)<br /> <br /> El splat de KASAN se vería similar a:<br /> BUG: KASAN: slab-out-of-bounds en ramoops_pstore_read+0x...<br /> Lectura de tamaño N en la dirección ... por la tarea ...<br /> <br /> Es probable que las condiciones sean extremadamente difíciles de alcanzar:<br /> <br /> 0. Fallo con una escritura de ramoops de menos de record-max-size bytes.<br /> 1. Reinicio: ramoops se registra, pstore_get_records(0) lee el fallo antiguo, asigna old_log con tamaño X<br /> 2. Gestor de fallos registrado, temporizador iniciado (si pstore_update_ms &gt;= 0)<br /> 3. Ocurre un oops (no fatal, el sistema continúa)<br /> 4. pstore_dump() escribe el oops a través de ramoops_pstore_write() tamaño Y (&gt;X)<br /> 5. pstore_new_entry = 1, se llama a pstore_timer_kick()<br /> 6. El sistema continúa ejecutándose (no es un oops de pánico)<br /> 7. El temporizador se activa después de pstore_update_ms milisegundos<br /> 8. pstore_timefunc() ? schedule_work() ? pstore_dowork() ? pstore_get_records(1)<br /> 9. ramoops_get_next_prz() ? persistent_ram_save_old()<br /> 10. buffer_size() devuelve Y, pero old_log es de X bytes<br /> 11. Y &gt; X: memcpy_fromio() desborda la pila<br /> <br /> Requisitos:<br /> - existe un registro de fallo anterior que no llenó el tamaño del registro (casi imposible ya que el gestor de fallos escribe tanto como puede caber en el registro, limitado por el tamaño máximo del registro y el búfer kmsg casi siempre excede el tamaño máximo del registro)<br /> - pstore_update_ms &gt;= 0 (deshabilitado por defecto)<br /> - Oops no fatal (el sistema sobrevive)<br /> <br /> Libera y reasigna el búfer cuando el nuevo tamaño difiere del tamaño previamente asignado. Esto asegura que old_log siempre tenga espacio suficiente para los datos que se están copiando.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> AppArmor: Permitir que apparmor maneje tablas dfa no alineadas<br /> <br /> Las tablas dfa pueden originarse desde el kernel o el espacio de usuario y la alineación de 8 bytes no siempre está garantizada y como tal puede desencadenar accesos a memoria no alineados en varias arquitecturas. Resultando en lo siguiente<br /> <br /> [ 73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720<br /> [ 74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom<br /> sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common<br /> [ 74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE<br /> [ 74.536543] Call Trace:<br /> [ 74.568561] [] dump_stack+0x8/0x18<br /> [ 74.633757] [] __warn+0xd8/0x100<br /> [ 74.696664] [] warn_slowpath_fmt+0x34/0x74<br /> [ 74.771006] [] aa_dfa_unpack+0x6cc/0x720<br /> [ 74.843062] [] unpack_pdb+0xbc/0x7e0<br /> [ 74.910545] [] unpack_profile+0xbe0/0x1300<br /> [ 74.984888] [] aa_unpack+0xe0/0x6a0<br /> [ 75.051226] [] aa_replace_profiles+0x64/0x1160<br /> [ 75.130144] [] policy_update+0xf0/0x280<br /> [ 75.201057] [] profile_replace+0xa8/0x100<br /> [ 75.274258] [] vfs_write+0x90/0x420<br /> [ 75.340594] [] ksys_write+0x4c/0xe0<br /> [ 75.406932] [] sys_write+0x14/0x40<br /> [ 75.472126] [] linux_sparc_syscall+0x34/0x44<br /> [ 75.548802] ---[ end trace 0000000000000000 ]---<br /> [ 75.609503] dfa blob stream 0xfff0000008926b96 not aligned.<br /> [ 75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720<br /> <br /> Solucionarlo utilizando las funciones auxiliares get_unaligned_xx().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: fsl-edma: no deshabilitar explícitamente los relojes en .remove()<br /> <br /> Los relojes en fsl_edma_engine::muxclk se asignan y habilitan con<br /> devm_clk_get_enabled(), lo que automáticamente libera estos recursos,<br /> pero estos relojes también se deshabilitan manualmente en fsl_edma_remove(). Esto<br /> causa advertencias al eliminar el controlador para cada reloj:<br /> <br /> edma_module ya deshabilitado<br /> ADVERTENCIA: CPU: 0 PID: 418 at drivers/clk/clk.c:1200 clk_core_disable+0x198/0x1c8<br /> [...]<br /> Traza de llamada:<br /> clk_core_disable+0x198/0x1c8 (P)<br /> clk_disable+0x34/0x58<br /> fsl_edma_remove+0x74/0xe8 [fsl_edma]<br /> [...]<br /> ---[ fin de la traza 0000000000000000 ]---<br /> edma_module ya no preparado<br /> ADVERTENCIA: CPU: 0 PID: 418 at drivers/clk/clk.c:1059 clk_core_unprepare+0x1f8/0x220<br /> [...]<br /> Traza de llamada:<br /> clk_core_unprepare+0x1f8/0x220 (P)<br /> clk_unprepare+0x34/0x58<br /> fsl_edma_remove+0x7c/0xe8 [fsl_edma]<br /> [...]<br /> ---[ fin de la traza 0000000000000000 ]---<br /> <br /> Solucionar estas advertencias eliminando la llamada innecesaria a fsl_disable_clocks()<br /> en fsl_edma_remove().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> NFS/localio: prevenir la recursión de recuperación directa en NFS a través de nfs_writepages<br /> <br /> LOCALIO es una optimización de montaje de bucle invertido de NFS que evita usar la red para LECTURA, ESCRITURA y COMMIT si se determina que el cliente y el servidor NFS están en el mismo sistema. Pero debido a que LOCALIO sigue siendo fundamentalmente &amp;#39;solo montaje de bucle invertido de NFS&amp;#39;, es susceptible a un interbloqueo por recursión a través de la recuperación directa, por ejemplo: NFS LOCALIO hasta XFS y luego de vuelta a NFS a través de nfs_writepages.<br /> <br /> Solucionar el potencial de LOCALIO para el interbloqueo por recuperación directa asegurando que todas sus asignaciones de caché de página se realicen desde el contexto GFP_NOFS.<br /> <br /> Gracias a Ben Coddington por señalar el commit ad22c7a043c2 (&amp;#39;xfs: prevenir desbordamientos de pila por asignación de caché de página&amp;#39;).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> clocksource/drivers/timer-sp804: Corregir un Oops cuando se llama a read_current_timer en plataformas ARM32 donde el SP804 no está registrado como el sched_clock.<br /> <br /> En SP804, el temporizador de retardo comparte la misma instancia de clkevt con sched_clock. En algunas plataformas, cuando se llama a sp804_clocksource_and_sched_clock_init con use_sched_clock no establecido en 1, sched_clkevt no se inicializa correctamente. Sin embargo, sp804_register_delay_timer se invoca incondicionalmente, y read_current_timer() posteriormente llama a sp804_read en un sched_clkevt no inicializado, lo que lleva a un Oops del kernel al acceder a sched_clkevt-&gt;value.<br /> <br /> Declarar una instancia de clkevt dedicada exclusivamente para el temporizador de retardo, en lugar de compartir el mismo clkevt con sched_clock. Esto asegura que read_current_timer continúe funcionando correctamente independientemente de si SP804 es seleccionado como el sched_clock.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gpio: cdev: Evitar desreferencia de NULL en linehandle_create()<br /> <br /> En linehandle_create(), hay una declaración como esta:<br /> retain_and_null_ptr(lh);<br /> <br /> Poco después, hay una impresión de depuración que desreferencia &amp;#39;lh&amp;#39;, lo que provocará un fallo.<br /> <br /> Evitar el fallo usando handlereq.lines, que es el mismo valor.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> procfs: corrige la falta de protección RCU al leer real_parent en do_task_stat()<br /> <br /> Al leer /proc/[pid]/stat, do_task_stat() accede a task-&gt;real_parent sin la protección RCU adecuada, lo que lleva a:<br /> <br /> cpu 0 cpu 1<br /> ----- -----<br /> do_task_stat<br /> var = task-&gt;real_parent<br /> release_task<br /> call_rcu(delayed_put_task_struct)<br /> task_tgid_nr_ns(var)<br /> rcu_read_lock real_parent!<br /> task_pid_ptr real_parent.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix block_group_tree dirty_list corruption<br /> <br /> When the incompat flag EXTENT_TREE_V2 is set, we unconditionally add the<br /> block group tree to the switch_commits list before calling<br /> switch_commit_roots, as we do for the tree root and the chunk root.<br /> However, the block group tree uses normal root dirty tracking and in any<br /> transaction that does an allocation and dirties a block group, the block<br /> group root will already be linked to a list by the dirty_list field and<br /> this use of list_add_tail() is invalid and corrupts the prev/next<br /> members of block_group_root-&gt;dirty_list.<br /> <br /> This is apparent on a subsequent list_del on the prev if we enable<br /> CONFIG_DEBUG_LIST:<br /> <br /> [32.1571] ------------[ cut here ]------------<br /> [32.1572] list_del corruption. next-&gt;prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538)<br /> [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607<br /> [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none)<br /> [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014<br /> [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120<br /> [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202<br /> [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538<br /> [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00<br /> [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff<br /> [32.1599] R10: ffffffff8288c200 R11: ffffffff828e4200 R12:ffff958890201538<br /> [32.1601] R13: ffff95889326e958 R14: ffff958895c24000 R15:ffff958890202538<br /> [32.1603] FS: 00007f0c28eb5740(0000) GS:ffff958af2bd2000(0000)knlGS:0000000000000000<br /> [32.1605] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [32.1607] CR2: 00007f0c28e8a3cc CR3: 0000000109942005 CR4:0000000000370ef0<br /> [32.1609] Call Trace:<br /> [32.1610] <br /> [32.1611] switch_commit_roots+0x82/0x1d0 [btrfs]<br /> [32.1615] btrfs_commit_transaction+0x968/0x1550 [btrfs]<br /> [32.1618] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs]<br /> [32.1621] __iterate_supers+0xe8/0x190<br /> [32.1622] ? __pfx_sync_fs_one_sb+0x10/0x10<br /> [32.1623] ksys_sync+0x63/0xb0<br /> [32.1624] __do_sys_sync+0xe/0x20<br /> [32.1625] do_syscall_64+0x73/0x450<br /> [32.1626] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [32.1627] RIP: 0033:0x7f0c28d05d2b<br /> [32.1632] RSP: 002b:00007ffc9d988048 EFLAGS: 00000246 ORIG_RAX:00000000000000a2<br /> [32.1634] RAX: ffffffffffffffda RBX: 00007ffc9d988228 RCX:00007f0c28d05d2b<br /> [32.1636] RDX: 00007f0c28e02301 RSI: 00007ffc9d989b21 RDI:00007f0c28dba90d<br /> [32.1637] RBP: 0000000000000001 R08: 0000000000000001 R09:0000000000000000<br /> [32.1639] R10: 0000000000000000 R11: 0000000000000246 R12:000055b96572cb80<br /> [32.1641] R13: 000055b96572b19f R14: 00007f0c28dfa434 R15:000055b96572b034<br /> [32.1643] <br /> [32.1644] irq event stamp: 0<br /> [32.1644] hardirqs last enabled at (0): [] 0x0<br /> [32.1646] hardirqs last disabled at (0): []copy_process+0xb37/0x2260<br /> [32.1648] softirqs last enabled at (0): []copy_process+0xb37/0x2260<br /> [32.1650] softirqs last disabled at (0): [] 0x0<br /> [32.1652] ---[ end trace 0000000000000000 ]---<br /> <br /> Furthermore, this list corruption eventually (when we happen to add a<br /> new block group) results in getting the switch_commits and<br /> dirty_cowonly_roots lists mixed up and attempting to call update_root<br /> on the tree root which can&amp;#39;t be found in the tree root, resulting in a<br /> transaction abort:<br /> <br /> [87.8269] BTRFS critical (device nvme1n1): unable to find root key (1 0 0) in tree 1<br /> [87.8272] ------------[ cut here ]------------<br /> [87.8274] BTRFS: Transaction aborted (error -117)<br /> [87.8275] WARNING: fs/btrfs/root-tree.c:153 at 0x0, CPU#4: sync/703<br /> [87.8285] CPU: 4 UID: 0 PID: 703 Comm: sync Not tainted 6.18.0 #25 PREEMPT(none)<br /> [87.8287] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-4.fc41 0<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath12k: limpiar el mapeo de enlace obsoleto de ahvif-&gt;links_map<br /> <br /> Cuando un arvif es inicializado en modo STA no-AP pero la preparación de la conexión MLO falla antes de que el arvif sea creado (arvif-&gt;is_created permanece falso), la ruta de error intenta eliminar todos los enlaces. Sin embargo, la eliminación de enlaces solo se ejecuta cuando arvif-&gt;is_created es verdadero. Como resultado, ahvif retiene una entrada obsoleta de arvif que está inicializado pero no creado.<br /> <br /> Cuando un nuevo arvif es inicializado con el mismo id de enlace, este mapeo obsoleto dispara el siguiente WARN_ON.<br /> <br /> ADVERTENCIA: drivers/net/wireless/ath/ath12k/mac.c:4271 en ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k], CPU#3: wpa_supplicant/275<br /> <br /> Traza de llamada:<br /> ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k] (P)<br /> drv_change_vif_links+0xbc/0x1a4 [mac80211]<br /> ieee80211_vif_update_links+0x54c/0x6a0 [mac80211]<br /> ieee80211_vif_set_links+0x40/0x70 [mac80211]<br /> ieee80211_prep_connection+0x84/0x450 [mac80211]<br /> ieee80211_mgd_auth+0x200/0x480 [mac80211]<br /> ieee80211_auth+0x14/0x20 [mac80211]<br /> cfg80211_mlme_auth+0x90/0xf0 [cfg80211]<br /> nl80211_authenticate+0x32c/0x380 [cfg80211]<br /> genl_family_rcv_msg_doit+0xc8/0x134<br /> <br /> Solucione este problema desasignando el vif de enlace y limpiando ahvif-&gt;links_map si arvif solo está inicializado pero no creado.<br /> <br /> Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> octeontx2-af: Solución a la caída del controlador PF con el arranque del kernel kexec<br /> <br /> Durante un reinicio kexec, el hardware no se apaga y enciende, por lo que el estado de AF del kernel antiguo puede persistir en el nuevo kernel. Cuando los controladores AF y PF se compilan como módulos, el controlador PF puede sondear antes de que AF reinicialice el hardware.<br /> <br /> El controlador PF trata la revisión del bloque RVUM como una indicación de que la inicialización de AF está completa. Si este valor se deja sin borrar al apagar, PF puede asumir incorrectamente que AF está listo y acceder a un estado de hardware obsoleto, lo que lleva a una caída.<br /> <br /> Borrar la revisión del bloque RVUM durante el apagado de AF para evitar que PF detecte incorrectamente la disponibilidad de AF después de kexec.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> MIPS: Solución alternativa para el error de LLVM cuando gp se usa como variable de registro global<br /> <br /> En MIPS, __current_thread_info se define como una variable de registro global ubicada en $gp, y simplemente se le asigna una nueva dirección durante la reubicación del kernel.<br /> <br /> Esto, sin embargo, se rompe con LLVM, que siempre restaura $gp si encuentra que $gp ha sido sobrescrito de alguna forma, incluso cuando es intencionalmente a través de una variable de registro global. Esto va en contra de la documentación de GCC[1], que requiere que un registro guardado por la función llamada, utilizado como variable de registro global, no sea restaurado si ha sido sobrescrito.<br /> <br /> Como resultado, $gp continuará apuntando al kernel no reubicado después del epílogo de relocate_kernel(), lo que lleva a un fallo temprano en init_idle,<br /> <br /> [ 0.000000] CPU 0 No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90<br /> [ 0.000000] Oops[#1]:<br /> [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY<br /> [ 0.000000] Tainted: [W]=WARN<br /> [ 0.000000] Nombre del hardware: loongson,loongson64v-4core-virtio<br /> [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000<br /> [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240<br /> [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001<br /> [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002<br /> [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80<br /> [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80<br /> [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90<br /> [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90<br /> [ 0.000000] Hi : 0000000000000000<br /> [ 0.000000] Lo : 0000000000000000<br /> [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270<br /> [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270<br /> [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL<br /> [ 0.000000] Cause : 00000008 (ExcCode 02)<br /> [ 0.000000] BadVA : 0000000000000000<br /> [ 0.000000] PrId : 00006305 (ICT Loongson-3)<br /> [ 0.000000] Proceso swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)<br /> [ 0.000000] Pila : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000<br /> [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528<br /> [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000<br /> [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258<br /> [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98<br /> [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000<br /> [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000<br /> [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002<br /> [ 0.000000] ...<br /> [ 0.000000] Rastro de llamadas:<br /> [ 0.000000] [] init_idle+0x130/0x270<br /> [ 0.000000] [] sched_init+0x5c8/0x6c0<br /> [ 0.000000] [] start_kernel+0x27c/0x7a8<br /> <br /> Este error ha sido reportado a LLVM[2] y afecta a las versiones desde (al menos) la 18 hasta la 21. Evitemos esto usando ensamblador en línea para asignar $gp antes de que una solución esté ampliamente disponible.