Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: static_call: Reemplazar WARN_ON() sin sentido en static_call_module_notify() static_call_module_notify() activa un WARN_ON() cuando la asignación de memoria fallo en __static_call_add_module(). Esto no está realmente justificado, porque el caso de fallo debe ser manejado correctamente por la cadena de llamadas conocida y el código de error se pasa a la aplicación de espacio de usuario que la inicia. Un error en la asignación de memoria no es un problema fatal, pero WARN_ON() deja fuera de servicio la máquina cuando se establece panic_on_warn. Reemplázalo con un pr_warn().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: batería: se corrige un posible fallo al anular el registro de un gancho de batería Cuando un gancho de batería devuelve un error al añadir una batería nueva, el gancho de batería se anula automáticamente el registro. Sin embargo, el proveedor del gancho de batería no puede saberlo, por lo que más tarde llamará a battery_hook_unregister() en el gancho de batería ya anulado, lo que provocará un fallo. Solucione esto utilizando el encabezado de lista para marcar los ganchos de batería ya anulados como ya anulados para que battery_hook_unregister() pueda ignorarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige el error null-ptr-deref cuando falla la carga del diario. Durante el proceso de montaje, si journal_reset() falla debido a que el diario es demasiado corto, entonces provoca que jbd2_journal_load() falle con j_sb_buffer NULL. Posteriormente, ocfs2_journal_shutdown() llama a jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), lo que da como resultado un error de desreferencia de puntero nulo. Para resolver este problema, debemos verificar el indicador JBD2_LOADED para asegurarnos de que el diario se cargó correctamente. Además, use journal en lugar de osb->journal directamente para simplificar el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: arreglo de acceso fuera de los límites a la matriz en las estadísticas de SoC Actualmente, la matriz ath12k_soc_dp_stats::hal_reo_error está definida con un tamaño máximo de DP_REO_DST_RING_MAX. Sin embargo, la función ath12k_dp_rx_process() accede a ath12k_soc_dp_stats::hal_reo_error utilizando el ID de anillo SRNG de destino REO, lo cual es incorrecto. El ID de anillo SRNG difiere del ID de anillo normal, y este uso conduce a un acceso a la matriz fuera de los límites. Para solucionar este problema, modifique ath12k_dp_rx_process() para utilizar el ID de anillo normal directamente en lugar del ID de anillo SRNG para evitar el acceso a la matriz fuera de los límites. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no leer con anticipación el inodo de reubicación en RST En la reubicación, hacemos lectura anticipada en el inodo de reubicación, pero si el sistema de archivos está respaldado por un árbol de bandas RAID, podemos obtener ENOENT (por ejemplo, debido a que las extensiones preasignadas no se asignan en el RST) a partir de la búsqueda. Pero readahead no maneja el error y envía lecturas no válidas al dispositivo, lo que causa una afirmación en el código de la lista scatter-gather: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cortar aquí ]------------ ¡ERROR del kernel en include/linux/scatterlist.h:115! Ups: código de operación no válido: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs No contaminado 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 000000000000000 RBX: 000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Seguimiento de llamadas: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Código: No se puede acceder a los bytes del código de operación en 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Módulos vinculados en: ---[ fin del seguimiento 000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Núcleo p ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: l2tp: evitar un posible desbordamiento del recuento de referencias del túnel Cuando se crea una sesión, establece un puntero hacia atrás a su túnel. Cuando el recuento de referencias de la sesión cae a 0, l2tp_session_free descarta el recuento de referencias del túnel si session->tunnel no es NULL. Sin embargo, session->tunnel se establece en l2tp_session_create, antes de que el recuento de referencias del túnel se incremente mediante l2tp_session_register, lo que deja una pequeña ventana donde session->tunnel no es NULL cuando el recuento de referencias del túnel no se ha incrementado. Mover la asignación a l2tp_session_register es trivial, pero l2tp_session_create llama a l2tp_session_set_header_len, que usa session->tunnel para obtener el encap del túnel. Agregue un argumento de encap a l2tp_session_set_header_len para evitar usar session->tunnel. Si las sesiones l2tpv3 tienen identificadores en conflicto, es posible que l2tp_v3_session_get compita con l2tp_session_register y obtenga una sesión que aún no tenga configurado session->tunnel. Agregue una verificación para este caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: Corrige la posible desreferencia de puntero NULL en gpiod_get_label() En `gpiod_get_label()`, es posible que `srcu_dereference_check()` pueda devolver un puntero NULL, lo que lleva a un escenario en el que se accede a `label->str` sin verificar si `label` en sí es NULL. Este parche agrega una comprobación NULL adecuada para `label` antes de acceder a `label->str`. La comprobación para `label->str != NULL` se elimina porque `label->str` nunca puede ser NULL si `label` no es NULL. Esto corrige el problema en el que el nombre de la etiqueta se imprimía como `(efault)` al volcar el archivo GPIO de sysfs cuando `label == NULL`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Impedir el acceso a puntero nulo en xe_migrate_copy xe_migrate_copy está diseñado para copiar el contenido de los recursos de TTM. Cuando el recurso de origen es nulo, activará una desreferencia de puntero NULL en xe_migrate_copy. Para evitar esta situación, actualice el indicador de origen a verdadero para este caso; el indicador activará xe_migrate_clear en lugar de xe_migrate_copy. Rastreo de problemas: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Paso 14, tamaños: 4194304 y 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Paso 15, tamaños: 4194304 y 4194304 <1> [317.128055] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000010 <1> [317.128064] #PF: acceso de lectura del supervisor en modo núcleo <1> [317.128066] #PF: error_code(0x0000) - no presente página <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Ups: Ups: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Contaminado: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Contaminado: [U]=USUARIO, [N]=PRUEBA <4> [317.128080] Nombre del hardware: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 29/07/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Código: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] X: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 00000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Seguimiento de llamadas: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209]? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] +0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit]---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc_submit: agregar bloqueo faltante en wedged_fini Cualquier cola no en cuña puede tener un recuento de referencias cero aquí y puede ejecutarse simultáneamente con una destrucción de cola asincrónica, por lo tanto, desreferenciar el ptr de la cola para verificar el estado de cuña después de la búsqueda puede activar UAF si la cola no está en cuña. Solucione esto manteniendo el bloqueo submission_state en torno a la verificación para posponer la liberación y hacer que la verificación sea segura, antes de volver a soltarlo en torno a put() para evitar el punto muerto. (seleccionado de el commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/inode: Evitar que dump_mapping() acceda a dentry.d_name.name no válido Se observa que se produce un bloqueo durante la eliminación activa de un dispositivo de memoria, en el que el usuario está accediendo a hugetlb. Consulte el seguimiento de llamadas de la siguiente manera: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 14045 en arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Módulos vinculados en: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl No contaminado 6.10.0-rc2-lizhijian+ #492 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 01/04/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Código: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 000000000000000 RDX: 00000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> ERROR: no se puede manejar el error de página para la dirección: 0000000000001000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ fin del seguimiento 000000000000000 ]--- ERROR: no se puede manejar el error de página para la dirección: 0000000000001000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: cargado Tainted: GW 6.10.0-rc2-lizhijian+ #492 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Anteriormente, se han realizado algunas comprobaciones de cordura en dump_mapping() antes de que la función de impresión analice '%pd', aunque aún es posible encontrarse con un dentry.d_name.name no válido. Dado que dump_mapping() solo necesita volcar el nombre del archivo, recupérelo por sí mismo de una manera más segura para ----truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: evitar agregar interfaz a la lista dos veces cuando SER Si SER L2 ocurre durante el flujo de reanudación de WoWLAN, el flujo de agregar interfaz se activa mediante ieee80211_reconfig(). Sin embargo, debido al error de retorno de rtw89_wow_resume(), hará que el flujo de agregar interfaz se ejecute nuevamente, lo que dará como resultado una lista de adición doble y provocará un pánico del kernel. Por lo tanto, hemos agregado una verificación para evitar la doble adición de la lista. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/list_debug.c:37! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Contaminado: GWO 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Nombre del hardware: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 24/06/2021 Cola de trabajo: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Código: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 0 0 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 00000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Seguimiento de llamadas: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? sincronizar_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? Módulos vinculados en: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Registrar motivo de apagado 0x03 ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk_iocost: corrige más cambios fuera de los límites Recientemente, la ejecución de UBSAN detectó algunos cambios fuera de los límites en la función ioc_forgive_debts(): UBSAN: cambio fuera de los límites en block/blk-iocost.c:2142:38 el exponente de cambio 80 es demasiado grande para el tipo de 64 bits 'u64' (también conocido como 'unsigned long long') ... UBSAN: cambio fuera de los límites en block/blk-iocost.c:2144:30 el exponente de cambio 80 es demasiado grande para el tipo de 64 bits 'u64' (también conocido como 'unsigned long long') ... Seguimiento de llamadas: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... No se identificó el impacto real de este problema, pero propongo corregir el comportamiento indefinido. La solución propuesta para evitar esos cambios fuera de los límites consiste en precalcular el exponente antes de usarlo en las operaciones de cambio tomando el valor mínimo del exponente real y la cantidad máxima posible de bits.